A basic / test locker for Android

This is an analysis of sample sha256 73fae61d9550186c9b68c0e3a0589f1faaa87f6a9dc8290f98aaf55db3a58350, which was uploaded to VirusTotal on July 1, 2021. It is detected as Android/Locker.CQ!tr. This malware appears as a test screen locker, with an explicit application icon “Virus”, and very few classes.

Update Jan 10, 2023: this simple malware is still active in January 2023. Package “com.aide.ui” is a genuine development package (not malicious). Providing the unlock password only works for a few seconds. See below for details.

Overview

The sample’s name is explicit: “Virus”. The package name evocates a test malware written by a student or wanna-be malware author. MobSF says the sample is “secure”. Beware: this means the sample’s implementation does not have obvious vulnerabilities in it, not that the sample is “safe to use” (it is malicious!).

Most of Quark rules match with only little confidence. They are not relevant. With the custom set of rules, only one relevant crime shows up:

The malware apparently executes a shell command in its class ADRTLogCatReader. Indeed, if we check the code, we see it issues “logcat -v threadtime”. This displays system logs with the date, invocation time, priority, tag, and the PID and TID.

Locking the screen

We disassemble the code. There are only 5 classes of interest: MainActivity, MyService, BootReceiver, ADRTLogCatReader and ADRTSender.

The main activity (named MainActivity) sets up the ADRTLogCatReader class and starts MyService service.

Note lines ADRTLogCatReader.onContext, and startService(…)

ADRTLogCatReader communicates with another Android applications, whose package name is “com.aide.ui”. This is an IDE for developing Android applications on an Android device itself. It is not malicious. The class starts a thread that reads the system logs (using the logcat command we detected with Quark) and sends them line by line to the debugging app (the remaining functionalities in ADRTSender are not used).

MyService implements the malicious behaviour in a few lines. The idea consists in displaying a window which cannot be deleted on top of other things.

The service displays the lock screen window.

The lock screen window consists of the malware’s icon (setImageResource), a button (resources reveal this button is named “Unlock Devices”), an edit text, a red background (setBackgroundColor). The window is:

• Centered (gravity to CENTER),
• Type TYPE_PHONE. Read Android documentation and learn those are “non-application windows providing user interaction with the phone (in particular incoming calls). These windows are normally placed above all applications, but behind the status bar. In multiuser systems shows on all users’ windows.”
• Flag FLAG_ALLOW_LOCK_WHILE_SCREEN_ON, i.e the screen can by locked while the window is displayed.
• Width and height are set to -2, which corresponds to WRAP_CONTENT.

Lock screen in action. Exactly as we worked out through reverse engineering: red window with button and edit text, on top of the rest.

Unlocking the screen

Fortunately, there is a way to get rid of this window.

Method onClick() is called when the user clicks on the button “Unlock Devices”

The implementation of onClick() shows that if one enters the string “moises” in the edit field, it will kill the window (removeView). Unfortunately, as the service is re-started just after, this will be short lived happiness 😉

Wannabe attacker?

This malware is very simple, coded in a few lines, nothing stealthy nor tricky about it. Therefore, my guess is that it is written by a student or wannabe attacker.

If you are a computer security student or teacher, please refrain from doing so. Obviously your code which was meant just for you or a couple of “friends” ended up in the wild, where it can be used and abused beyond your intent. We, malware analysts, already have tons of malware samples to analyze. Want to work on something cool? Try reversing malware! You will learn as much, and your actions will be positive.