Tag Archives: android

How to create the perfect REST API documentation #apicraft #api

Somehow I’m pretty pumped about the fact that I was able to just create a markdown file that describes my API (blueprint), adjust and run my integration tests driven by it (dredd), and once everything passed, simply ship it to my partners/users/contractors knowing that it will be a 100% up-to-date, readable and actionable documentation.

I’m also pretty sure that somehow, somewhere this totally breaks HATEOAS (of the “this ish documents itself” school of thought), and that maybe Swagger or something else might handle some use cases much better, but for now I’m just going to enjoy the fact that once the tests are done, I can just point all the parties involved to one file, followed, in full confidence, by the magic word – RTFM!

a way to slowly sunset the open source competition #android

One has to wonder about the future and the motivation for the open source Android anymore. Some conspiracy-theory-inclined folks have speculated that the master plan all along has been to attract people to the open-source Android, then slowly get the thought leaders/developers hooked on Google Play Services with proprietary lock-in i mean value add. Surprisingly, leaving gaping holes in what seems to be a poorly maintained open-source alternative codebase fits right into such hypothetical plan:

Currently, there is not much that users can do to avoid this problem. They can opt to use [mobile] browsers that are not affected by this vulnerability, such as Chrome or Firefox.

…and then just let FUD as well as real security fiascos put the open-source alternative to rest. Of course, personally I’m not into conspiracy theories, but it would be upsetting if the events took a turn in that direction. As a user, I chose Android because it’s very hackable in a good sense, and because it’s open. It would be really sad to see any of that change.

nth world problems

A pretty healthy number of downloads for an Android app on this planet (btw not the only app in the range)

Screen Shot 2014-08-27 at 11.05.14 PM

Bet that adds some motivation for an extra day or two of some independent pen testing. Also bet Google didn’t spend too much time sweating the impending int32 overflow when they first rolled out those counters.

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.

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 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?