Porno-locker - nice icon, not so nice functions

Recently @PaulWebSec made me look at porn (now, will you risk clicking on that link? ;). Well, at least he advertised it as such, but it turned out to be just another fake Android porn app, which in reality was just a ransomware. It even has a kind of NSFW icon, but you have to get the sample to see it for yourself.

Anyhow, let's have a look at the code. It uses a lot of interesting permissions: camera, call log, contacts, Internet (of course), location and so on. It also has a bunch of activities, one of which is affectingly called TerrifyActivity.

Overview

When we start the app, AndroidManifest says it will start an Activity called MainActivity. And by looking at it it does nothing. Absolutely nothing, apart from creating some variables. Actually, the startup code is in the MainApplication class. This, in turn, starts the MainService3 class. A WakeLock is also put in place - to make sure that the device is on. We are asked whether we will allow this app to be Device Admin. It does not use any polices, it just wants to be the Device Admin so we won't be able to uninstall it using pm uninstall command.



This locker also can use Camera - class b takes a picture and saves it as fastness.jpg. Then, by using code in class h this picture can be downloaded by any website loaded to WebView via exposed JavascriptInterface. What this means is that the attacker can easily obtain a picture of the victim using Javascript. Interesting functionality.

Class e is responsible for the device locking. It implements three listeners: View.OnClickListener, View.OnKeyListener, View.OnTouchListener. Each of them is responsible for intercepting different event and making sure that the lock screen stays on top. By intercepting this events we cannot change the View and the phone seems locked.

In order to be even more persistent the view has the following flags specified:

  • FLAG_LAYOUT_IN_SCREEN - take entire screen.

  • FLAG_FULLSCREEN  - hide decorations.

  • FLAG_SHOW_WHEN_LOCKED - shows a window even when the screen is locked.

  • FLAG_DISMISS_KEYGUARD - no keyguard.

  • FLAG_TURN_SCREEN_ON - screen is always on.

  • FLAG_HARDWARE_ACCELERATED  - hardware acceleration. Because, why not?

As you can see this provides an almost kiosk-like mode on your device. Fully locked. Well, you can still kill the process from the adb I guess :) However, there is a slight bug. You cannot scroll the website, because the scrollbar has been disabled. So, you get the message shown above, but you cannot do anything about it.

There is also an interesting BroadcastReceiver called MainReceiver2 that responds to a couple of intents:


This is to make sure that the locker is running, even if we e.g. reboot the phone. A bit aggressive, don't you think?

Other interesting stuff: every time you change your location it is saved in the eloquence.xml shared preferences. Class g is responsible for that and implements a rather interesting Android feature called MessageQueues. Speaking of the shared preferences, here is a small snippet of this file:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <boolean name="joyousness" value="true" />
    <boolean name="inkling" value="true" />
    <boolean name="appraisals" value="true" />
    <int name="semaphoring" value="4" />
    <string name="mouse">0.0</string>
    <string name="reeling">0.0</string>
    <boolean name="dovecote" value="true" />
    <string name="leader">{}</string>
    <boolean name="thickness" value="true" />
    <string name="raft">73d79f35-9577-4e86-a747-eddd876632c8</string>
</map>

As you can see names are rather strange. For example mouse and reeling are the location parameters. And, just to top things up, below are the basic device information that are stolen.


Reports are sent in a base64-encoded JSON format. For debugging purposes also stacktraces are sent via this channel. In the end user is presented with a kiosk-like WebView of a website that the attacker has prepared.

Obfuscation

The class net.biologist.a contains all of the "encrypted" strings. This are just base64-decoded string that have been prefixed with some random values. So, first you have to de-base64 and then just start reading them starting from a specific index. All of the decrypted strings, along with their indices in hex and decimal are available here.



Class net.biologist.cf on the other hand is something quite interesting. Most of the functions used in the sample are hidden there and are obfuscated by using a different, meaningless name. For example instead of invoking StringBuilder append method on String, you would call cf.c101(StringBuilder, String). A snippet of this class is presented on the screenshot below.

Class c if also used for obfuscation - some of the strings from a class are even further obfuscated by assigning them to some random members of the c class, as pictured below.


Android Malware Tracker

And now for something completely different. As you may be aware from my Twitter I started a really small project called Android Malware Tracker - amtrckr.info. The idea behind it is that sometimes I encounter a sample that I have already described or is interesting, but I don't have time to take a closer look and I want to put it out there. And that's my way of "putting it out there" and, as a bonus, you get the C&C data. And there even is an API so that you can easily put URLs, IPs or domains on your blacklists. Have fun and if you have some interesting sample you know where to find me.

Comments

Post a Comment

Popular posts from this blog

Having fun with AndroidManifest.xml

Image
Before w will get back to Sandrorat let's have some fun. It's weekend after all, or rather it was weekend when I wrote this post. Everyone that ever tried to see the insides of the APK file knows what's an AndroidManifest.xml file is. Some even know that, inside the APK, it's not a real XML, but rather a compressed, binary form of an original XML. This compressed form was first abused in the Android.OBAD malware . Compressed form of an XML differs with the real XML in at least one key aspect, hidden in the String Pool. Let's have a look at a compressed AndroidManifest.xml file of the previously mentioned Sandrorat sample and see if we can do something interesting with it. If you want to skip directly to the fun part, just ignore the next section.
Read more

Android malware based on SMS encryption and with KitKat support

Image
Most of the malware based on the SMS C&C communication channel is not compatible with Android 4.4 KitKat. This is due to the fact that KitKat introduced a concept of one messaging app, which all other apps had to go trough before they send or handle a received text message. This prevented malware from hiding received short messages or sending without saving them in the "Sent" folder. Well, it wasn't hard to predict that this state of affairs wouldn't last long and that malware authors would eventually catch up. Malware described here not only supports KitKat, but also uses an open-source SMS encryption tool  as a basis for its code. Let's have a look at the insides of the new sample (hash: 84e2e9e8430792b583d02d3cc1bf8535 ) and let's call it SmsSecure, just for the sake of brevity.
Read more

Sandroid RAT analysis: Part I - synthetic communication

Image
My first post is about Sandrorat, a fairly new RAT tool that was prominent for being a part of a Polish spam campaign . The analyzed sample hash is bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d . Sample was obtained thanks to The Honeynet Project . Everything is synthetic First part will be about a little known synthetic methods and the way Sandrorat uses them to obfuscate the code . This sample declared three different services:
Read more