Tag Archives: apk

An #Android SMS Trojan that’s apparently not #malware

So I’m looking at this ad network, and I notice that some of its ads lead up to an Android binary download. Shady, right? Just the fact that there is an ad leading to a sideloaded APK is already pretty disturbing. I look around, find a whole family of those apps. For each app, at least half of all Virustotal vendors mark it as an SMS trojan, and so does Lookout.

So we contact well-meaning people who might be interested in hearing about those apps. They tell us it’s a false positive. I go back saying there is no way this could be a false positive, these apps send paid SMS messages and are recognized by top vendors as an SMS trojan. They argue back and still claim it’s an FP. So I run one of the apps in a sandbox, it’s basically a bunch of porn, but the first thing that shows up is a warning saying if the user continues with this app, it will charge X dollars via paid SMS for each video viewed. So I guess if they warn the user upfront about this, then they are legit?

So it seems, in this particular industry, it’s one way to bill the users. So going back to the
definition of mobile malware, how on Earth were the AV scanners supposed to read that initial warning to the user? By all characteristics available to machines, this app looked and acted exactly like an SMS trojan. That’s more bad news for mobile antivirus: since a large part of apps’ functionality is hidden on the server side, unavailable for signature matching, you end up over-analyzing whatever is left accessible to you on the device and detection starts to fall apart.

My favorite Google Play malware for this week

So contrary to some FUD reports, Google Play stays relatively malware-free. Which makes long-running apps like this one especially puzzling.

Enter The Videos Mania, which is active for at least about a year, has been downloaded between 100k and half a million times, and has ~7000 likes on Google+. Its developer has 8 other apps like ringtones and wallpapers, all of which require SMS permissions and all are reported as trojans by Lookout, though the Videos one is by far the most popular. The dude didn’t really bother fudging a proper-looking certificate, simply signing his creations as “DN: C=xx”.

This Videos app is marked by 31/54 Virustotal vendors as an SMS-sending trojan, so I’m just curious, doesn’t Google like own VT? Don’t they VT-scan the apps? Or maybe they do it once during app version releases, and if there are no VT alarms at the time, they never re-scan? Not sure, that doesn’t sound like Google. But here we are with this app, and some more of my favorites coming up in future posts.


So what is mobile #malware exactly?

Sifting through endless Virustotal scans, you realize that it’s not easy at all to define what exactly mobile malware is. Literally 90% of antivirus-reported malware APKs are nothing but trivial or repackaged apps with some annoying adware library slapped on top of it that doesn’t even do anything really bad. Why exactly is mobile malware so elusive and not as clear-cut as the good old desktop viruses? A couple of things come to mind:

  • The juicy parts often stay remote: unlike the classic desktop viruses and rootkits, a lot of mobile functionality remains on the server. So an app collects your banking password and sends it to server, that’s bad, right? Not if it’s a Bank of America server. What if it’s an Akamai or an EC2 server? What if it’s a Mint finance app server? This gets blurry really fast. Same with location apps – when an app constantly sends your location to a server, it’s cool if it’s your own account, and it’s suddenly not cool at all when someone else has access to that information on the server. Hard to automatically tell that just by looking at the mobile app tip of that iceberg. That’s why AV vendors came up with a euphemistic label “surveillanceware”, which means, “I have no idea if this app is bad or not, you have to look at it in your own context”.
  • No need to get sophisticated: most of what’s labeled as mobile malware are small-time scams. In the mobile world, there is no such thing as a multi-million dollar botnet industry commercially used for:
    • running spam
    • staging DOS attacks
    • collecting and laundering information

    I guess mobile can be useful only for the last point right now, we’ve yet to see the first two on mobile. So no need to build autonomous sophisticated botnet clients that pack tons of revealing functionality and patterns with them. Consequently, a lot of mobile scams look rather plain and not very different from regular apps.

  • No silent infections: it’s pointless to do port scanning and hard to use drive-by browser exploits on mobile. Combined with no incentive to make things complicated, the main vectors to get into someone’s phone are social engineering and brand abuse. Both of those are difficult to detect automatically, leaving a huge gray zone. Even the SMS scams: lots of legitimate apps have “share via SMS” functionality, good luck telling that from malware propagating itself via SMS, or sending messages to paid numbers that only become plaintext right before the message is sent.

So this leaves the traditional antivirus vendors especially helpless on mobile, best they can do so far is to report noisy adware or a few true malicious outliers that get outside the gray zone.

auto-clicking on things with #monkey #android

Android is nice because you can script the hell out of any part of it, and mess with the apps dynamically in any number of ways. For scripting the inputs, there are at least three ways to do it.

The good ol’ monkey with its monkeyrunner is the first thing that comes to mind: device.touch(x, y, ‘DOWN_AND_UP’) Sadly though, only some elements in a real app will honor monkey requests. After some logcatting we see how a monkey goes about generating a click:

D/MonkeyStub(12294): translateCommand: tap 551 1812
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
I/InputDispatcher(  714): Delivering touch to: action: 0x1

compared to a real tap on a screen:

D/InputReader(  714): Input event: value=1 when=2124062362000
I/InputReader(  714): Touch event's action is 0x0 (deviceType=0) [pCnt=1, s=0.122 ] when=2124062423000
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
D/InputReader(  714): Input event: value=0 when=2124153701000
I/InputReader(  714): Touch event's action is 0x1 (deviceType=0) [pCnt=1, s=] when=2124153701000
I/InputDispatcher(  714): Delivering touch to: action: 0x1

For those app UI elements that refuse to be monkeyed with, we can work with lower-level input events. One approach is to record a real tap (or any input sequence for that matter) with adb shell getevent and replay the same sequence with setevent like shown here. An easier approach is to simply use adb shell input with x and y:

adb shell input touchscreen tap 500 800

which gives us apparently a more palatable tap, and the following logcat output:

D/AndroidRuntime(16262): Calling main entry com.android.commands.input.Input
I/Input   (16262): injectMotionEvent: MotionEvent { action=ACTION_DOWN, id[0]=0, x[0]=500.0, y[0]=1870.0, toolType[0]=TOOL_TYPE_UNKNOWN, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=3300706, downTime=3300706, deviceId=0, source=0x1002 }
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
I/Input   (16262): injectMotionEvent: MotionEvent { action=ACTION_UP, id[0]=0, x[0]=500.0, y[0]=1870.0, toolType[0]=TOOL_TYPE_UNKNOWN, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=3300706, downTime=3300706, deviceId=0, source=0x1002 }
I/InputDispatcher(  714): Delivering touch to: action: 0x1

Happy clicking!

Brand-stealing apps

With Google Play tightening the security side with Virustotal and Bouncer (when the latter doesn’t crash, that is), you don’t see as much outright malware in that store anymore. However, one type of scammy apps that I still run into every week or so on Play are the ones that wrap some popular service, trying to get a cent or two from Admob.

Basically, it takes about 15 minutes to wrap any popular bank’s or web service’s mobile version in a WebView, stuff it with official-looking keywords, logos and descriptions, and publish on Play. Google can’t really do anything about it short of manual review of every single app. So anyone in the world (including some really not-so-well-off countries) who can write “hello world” for Android and subscribe to Admob, can then whip up a fully functional wrapper of a bank’s website, publish it in the US on Play, get a few hundred downloads from searches, and start collecting the Admob revenue.
For an extra bonus, they can also resell their install base to the real bad guys who can push a small update to the app and start stealing the actual credentials of the bank’s users. I don’t see an easy solution to this except the brands monitoring popular stores, and also trying to limit access to their services via WebView-like clients to at least raise the bar a bit for scammy developers. Because right now publishing a legit-looking service clone is ridiculously easy.

Android “antivirus” scam – still on Yahoo ad-running sites #malware

This year-old scam has resurfaced very prominently, and I’ve run into it on various websites that show Yahoo ads, indicating pretty massive malicious advertisement volume. A browser pop-up says the following:

Virus Affecting your Android? Turn on Virus Scanner NOW!

If you click “OK”, you can be taken to a variety of destinations, including:

  • a spammy but legit-looking dating app on Google Play with 50mil(!) downloads – I’d imagine malicious ads are partly responsible for that number, maybe via an affiliate?
  • a selection of some shady dating/porn sites
  • and best of all, a step-by-step guide for you to enable app install from unknown sources on your phone, and download a modified version of “Android Armour” APK binary with God knows what added functionality:


Very impressive, considering these friendly folks are basically talking people into opening up their phones to every other kind of evil garbage that comes up next.

I ran into this a bunch of times over the last few weeks, as recently as this weekend on Tumblr. I know Yahoo is trying to squash these as fast as humanly possible, but until then, beware. And again, in US, it’s a good idea to never install anything on Android from anywhere other than Play.

How mobile viruses and scams spread around

So apps are secure, because everyone gets them from the store, right? Um, no. That’s kind of the case for Apple’s platform, where you have to go out of your way to find malware, but with the Android shipments outnumbering iOS device shipments 6 to 1, the real fun for bad guys and researchers happens in the Androidland.

  • Third-party stores – you’d be surprised to find out that besides Play there are 500 app stores out there, of varying degrees of shadiness and security practices
  • “Review” forums and blogs – e.g., even a legit-looking site Androidpolice.com, who really should know better, instead of getting people into habit of only using Play, encourages them to directly download APKs from a weird-looking Androidfilehost.com “mirror”
  • Sending download links via SMS spam
  • Email spam – “email from dad” that passed all Gmail filters and let me download a malicious app binary on the phone
  • Twitter – as a bad guy, you get some followers, then start spraying links like download skype for mobile, and you got yourself a nice little install base for your scammy app
  • Ads on web and mobile, links on websites that redirect you to an app binary download
  • More bizarre ways like infecting via Bluetooth apparently

Just by watching and scraping some of these you can build yourself a sizable library of some pretty nasty stuff. Just watching the Twitter feed for some of those scams is pretty fascinating.

How to re-package an Android app – #apk 101 #reverseengineering

Android apps are actually (still) pretty easy to read and tweak. Although tools like Proguard are supposed to address that, a lot of developers don’t seem to bother, also any un-obfuscated APK that’s exported directly from your IDE of choice can be opened up and studied in its smali form.

One option is to use APK Manager that has a ton of options that cover most of this. But it’s also pretty easy to just do it step by step and have more control over the process, so here we go with some pseudo-bash steps:

      • Get the APK file to study or repackage with some code changes – say, test.apk
      • Download smali.jar and baksmali.jar (or the apktool, but that will have to be run a bit differently), also need a JDK with jarsigner
      • Create folders unzipped-apk/ and dex/, then:
unzip test.apk -d unzipped-apk/ # prepare the base
cp unzipped-apk/classes.dex .    # pull out dex for decompilation
rm -rf unzipped-apk/META-INF/ # remove old certificate info
java -jar baksmali.jar -o dex/ classes.dex
    • Now we can go to the dex/ folder, examine the .smali files and make the observations/changes that we need need. For example, just to study the app’s code, or comment out a pesky conditional in some method, or sprinkle a few debug printouts to understand what the app is exactly doing under the hood. When unobfuscated, smali is surprisingly easy to understand and tweak.
java -Xmx512M -jar smali.jar dex -o classes.dex # re-compiling
mv classes.dex unzipped-apk
cd unzipped-apk && zip -r new.unsigned.apk * # unsigned APK created
  • Create a key store somewhere, for example ~/android-keystore and alias “myks”, e.g.:
    • keytool -genkey -v -keystore android-keystore -alias myks -keyalg RSA -keysize 2048 -validity 10000
    • a keystore can also be created in Eclipse when exporting an APK from any Android project

    then we sign:

jarsigner -verbose -keystore ~/android-keystore \
-storepass example123 -keypass example123 -digestalg SHA1 \
-sigalg MD5withRSA \
-sigfile CERT -signedjar new.signed.apk \
new.unsigned.apk myks

So the new.signed.apk is ready to go on an Android device or an emulator. Keep in mind that it is signed with your key and is not zipaligned, but for debugging, tracing and research purposes that should not matter, right?

Making automatic calls from Android

Screen Shot 2013-10-24 at 11.52.01 PMSo apparently Android lets your app make outbound phone calls in multiple ways (as always), the most basic ones are either via activity with android.intent.action.CALL intent, which pulls up the dialer and fires off a phone call, or via ITelephony.call() library call. Both normally require android.permission.CALL_PHONE, unless you figure out a way to dodge the permission checks, but the former is harder to detect. While you can simply grep for the ITelephony case, the other one – action called with an intent – requires some control flow tracing, which gets messy fast. Of course, both can be obfuscated, but that is a different can of worms for another day.

Bottom line – every piece of information extracted from an Android APK carries some value – intents, activities, library calls, anything – because only the careful juxtaposition of all these types of facts lets us judge one way or another about an app.

Treasure trove of malware on Twitter

A month after Lookout’s report on SMS malware industry, these scams are alive and well on Twitter. A casual 10-minute search produces at least a dozen of shady stores and many fake, unauthorized or re-packaged APKs. The malware assembly website mentioned in that report, complete with templates of fake Skype and Google Play apps and their “conversion rates”, is still up and running. For the time being, queries like these a still great source of malware to study. And will probably remain so, since Twitter is a huge distribution opportunity – unlike the search engines, tweets are quickly indexed, harder to ban, and the scammers desperately need clicks and distribution, so this stream of garbage will not dry up anytime soon.