Analyzing and remediating a malware infested T95 TV box from Amazon

A couple of weeks ago, security news outlets made their rounds reporting on an Android TV box available on Amazon that came pre-installed with malware. The findings came from a Canadian developer, Daniel Milisic, who posted on his GitHub. What Daniel found was an Android T95 TV box infected with malware right out of the box!

Immediately, I recognized some of the apps that put up red flags, such as Adups. Under those circumstances, there’s only one logical thing a curious mobile malware researcher can do—I put in an IT Helpdesk request to buy a malware infested TV box! (For the record, I do not recommend putting in such a request at a non-information security company.)

The following is my analysis after days of obsessing over this little black box.

Toolset

Before we continue with my analysis, let me explain some of the tools I used so when they are referenced it makes more sense. This is for the average reader who is not a tech nerd like myself. If you are technically inclined and want to skip to the good stuff, head down to header Getting to the Core(java) of the case.

• Android Debug Bridge (adb)—I have referenced this command line tool many times in the past. It is your best friend into easily sending commands to an Android device via Windows, Mac, or Linux environments. It’s part of Android Studio, but unless you plan to develop an Android app, I recommend just grabbing the Android SDK Platform Tools. I have a great writeup on the Malwarebytes Forum on how to install adb and use it to remediate preinstalled malware.
• Telerik Fiddler Classic—Fiddler is an Internet traffic monitor with powerful HTTPS capturing capabilities. Most other internet traffic monitors can’t show details of HTTPS connections, because it is encrypted.  The powers of Fiddler can capture that traffic by installing a special certificate onto the device. Then by proxying internet traffic through a Windows machine, you can see otherwise private HTTPS traffic. The best part is it doesn’t require root access. That is unless you have a stubborn TV Box with no place in Settings to install certificates. Although more painful, there is a workaround to install with root access.
• NoRoot Firewall—This handy app allows or denies network traffic based on each individual app. More importantly, it also logs the traffic from each app, giving you a good baseline of what to look for in Internet traffic monitors. Although noisy at first, becasue you have to initially allow or deny every app that connects to the Internet, it’s worth it if your goal is to stop unwanted Internet traffic from particular apps in their tracks.
• Logcat —Good old Logcat! Another tool referenced quite often. This command line tool outputs logs of just about everything going on with an Android device.

Rooted in evil 

The first sign that something was not right with this TV box was the fact that it has a toggle switch for root access. (Hint: If you buy a TV box from Amazon Prime and it has a “Root switch” toggle, use the Prime free return policy right away.)

Whether the toggle switch is on or off, I am pretty sure it doesn’t matter because the box is rooted regardless.

To clarify, rooting in the context of Android devices means attaining the highest level of access—known as “root”. Among other things, this gives you the ability to modify system level directories and files, something regular Android users can’t do. This heightened access is made available mainly for developers who need access to test in a pre-production environment.

Once in production, Android devices are not rooted. In fact, if you run the command adb root on a production Android device, you get an error message stating

adbd cannot run as root in production builds

. On a rooted device, the message is restarting adbd as root or

adbd is already running as root

.

Important Warning: Rooting an Android device that is in production and thus does not have root access is very dangerous and can result in bricking the device, leaving it forever broken. In addition, allowing root access gives every app on the phone root access, including malware! We highly recommend you do not root your Android device. However, since the T95 TV box was already rooted, I used root for analysis and remediation.

Shell games

Another thing I should mention before moving on is a word about shell. Shell refers to interacting with the Linux command line. Since all Android devices are based on Linux, you can access the shell to run common Linux commands, along with other Android-specific commands installed on the device.

You can do this via the adb command 

shell

. For example, if you want to list all packages on an Android device, you could run pm list packages -f on the shell. You can do this in two ways. More commonly, you might tunnel the command using

adb shell pm list packages -f

. Or you can first go to the shell by using command adb shell, and then run

pm list packages -f

.

In this instance, the name of the shell on the T95 TV Box is walleye. The name of the shell changes based on the Android device’s manufacturer and model. Note that this is another oddity with the T95 TV Box. As a matter of fact, the shell name

walleye

is stolen from a Pixel 2 with the same name. (This information comes in handy later on.)

Okay, know that we went through the tedious details, lets get to the good stuff!

Getting to the Core(java) of the case

Daniel references in his GitHub the existence of a directory /data/system/Corejava. Testing with other Android devices I have sitting around confirms this directory should not exist—Including on a Pixel 2 (the box has the same shell name as a Pixel 2: Walleye).

If /data/system/Corejava was a common directory, surely the Pixel 2 with the same shell name as the T95 TV box would have this directory? Daniel also provides the contents of

/data/system/Corejava

from his T95 TV box. Within it contains an infected classes.dex file. Looking at my own T95 TV box, it in fact contains the same malicious directories and files:

The classes.dex is a DEX file that contains the machine code for an app to run. Every app, which is called an Android Package Kit (APK) on Android, contains a classes.dex file, along with other directories and files required for the classes.dex to load and run.

Therefore, there must be an APK installed for this classes.dex to work.

My next step was to analyze this malicious DEX file found in Corejava, or Corejava classes.dex—I will call it Corejava classes.dex for clarity.

Corejava classes.dex’s code contained a lot of references to using internet traffic: GET commands, POST commands, HTTP, HTTPS, etc. Looking at the VirusTotal results of the Corejava classes.dex found in my own T95 TV box aligned with it being a Trojan Downloader. The clearest evidence of this were URLs in the code. One of them was a malicious URL associated with other malicious DEX files and APKs:

hxxps://dy.kr.wildpettykiwi.info/dykr/update

With this evidence, I moved on to collecting network traffic.

Exploring the network traffic

When I am looking into network traffic, my very first step is installing NoRoot Firewall, as referenced in the Toolset section above. Looking at the logs of NoRoot, it appeared the T95 TV box had quite a bit of traffic coming from DGBLuancher.

This was of interest considering DGBLuancher, package name com.swe.dgbluancher, does not contain any references to using Internet traffic in the code.

Much of the traffic from DGBLuancher used port 443, which is for HTTPS traffic. Per the Toolset section, I think the best choice of network traffic monitors is Telerik Fiddler Classic. Capturing only an hour of traffic using Fiddler produced a massive list of entries!

The majority of the traffic came from random non-malicious news sites and ad sites. All of this was happening in the background, unseen, until you capture the Internet traffic! To be clear, this is malicious clicker activity, which generates revenue from pay-per-click ads.

But wait, there was more!

There was also a sprinkling of malicious URLs, including but not limited to malicious URLs from the code of Corejava classes.dex.

Tying it all together

Backing up, let’s look at the evidence so far. We have DGBLuancher with no evidence within the code of using Internet traffic capabilities, and we have Corejava classes.dex with lots of evidence within the code of using Internet traffic capabilities. And yet capturing Internet traffic shows a correlation to DGBLuancher, but with URLs from Corejava classes.dex.

My hypothesis was that DGBLuancher was the culprit APK loading and running Corejava classes.dex, but more testing needed to be done.

So, I first uninstalled DGBLuancher, but kept Corejava classes.dex. The result? Malicious Internet traffic stopped. Ergo, Corejava classes.dex cannnot run without DGBLuancher.

Next, I reinstalled DGBLuancher and removed Corejava classes.dex. Again, Malicious Internet traffic stopped. DGBLuancher could not produce malicious Internet traffic on its own. It needed Corejava classes.dex.

The obvious conclusion was that DGBLuancher was indeed the APK loading and running Corejava classes.dex!

If that wasn’t enough evidence, there was even more. If I deleted Corejava classes.dex from the /data/system/Corejava, it magically reappeared. This happened immediately after a reboot or if I simply waited long enough.  But, if I uninstalled DGBLuancher, Corejava classes.dex stops reappearing. With all the evidence, I had DGBLuancher dead to rights. It was the culprit loading and running Corejava classes.dex. 

The malicious behavior of DGBLuancher lands it with the classification of Android/Trojan.Downloader.CoreJava.T95. Despite this detection, Malwarebytes for Android cannot remediate due to DGBLuancher being a system app. For steps to remediate, see the Remediation section below.

The mystery of Corejava

Once I had established that DGBLuancher creates Corejava classes.dex, the next mystery was: What was creating /data/system/Corejava and the rest of its contents? You see, even when DGBLuancher was uninstalled, after removing 

/data/system/Corejava

, it would appear again. Everything except for the Corejava classes.dex file, of course.

Looking at what process was creating /data/system/Corejava, it appeared to be a process called

system_server

. (Note that depending on where you look, it can also be called system_process.)

By using command logcat | grep system_server in shell, I confirmed that

system_server

did a lot more than just create /data/system/Corejava. In fact, it seemed to run many of the most important tasks. You can really see how important

system_server

is by terminating it which results in the device crashing—I do not recommend.

The obvious conclusion was that system_server was a generic system process used by many other elements to run commands in the background. As a matter fact, DGBLuancher uses

system_server

to create Corejava classes.dex. Anything from a script to another app could be using system_server to create 

/data/system/Corejava

—system_server  is not the culprit itself, just a conduit.

With this information, I did everything from analyzing system level bash scripts on the device, looking for keywords such as Corejava within every file, to uninstalling apps to see if it resolved.

The only thing I neglected doing was uninstalling apps that would compromise the functionality of the device. After all, if the TV box cannot function, what’s the point of remediating? It pains me to say that this one is going to have to remain a mystery for now. This is no matter, since with DGBLuancher uninstalled the malware is neutralized. In addition, Daniel finds a clever way to stop the recreation that we will address below.

Remediation

Factory reset

I strongly recommend restarting the T95 TV box from a fresh factory reset before proceeding to remediation. If you’ve been using the TV box for a while, there’s a good chance other malware could have been downloaded during that time. As a result of resetting to factory, all of this will be removed, but keep in mind this will also erase all non-system related items on the device.

To factory reset the T95:

1. Go to the Gear icon for the settings screen
2. Navigate to More Settings
3. Navigate to Device Preferences
4. Scroll down to bottom and press Reset
   1. Read the warning, and proceed with Reset if you’re willing to go ahead

After the reset, do not connect the T95 TV box to a network just yet. Don’t do this until you have gone through remediating DGBLuancher in the next section. This will prevent any malware being installed via network download. 

Using adb

The first place you should start is installing adb onto a Windows, Mac, or Linux environment. (Check the Toolset section above on how to install.) Next, you will need to put the T95 TV box into Developer Mode and turn on USB0 device mode.

1. Go to the Gear icon for the settings screen
2. Navigate to About
3. Scroll down to Build
1. Press Build several times until it states You are now a Developer!
4. Press the Back button to return to settings screen
5. Navigate to More Settings
6. Navigate to Device Preferences > Developer options
7. Scroll down to Debugging section
1. Ensure these toggle switches are on
1. USB debugging (should be on by default)
2. USB0 device mode enable

Now that we have adb installed, and the T95 TV box in Developer Mode the next step is to test adb.

You will need a cable that can join your computer to the T95, which has a USB-A port. (If you can find USB-A to USB-A cable sitting around your place, congratulations, you have the rarest cable known to myself.)

With your comptuer connected to the T95 TV box, open a terminal (this is Command Prompt on Windows) and type:

adb devices

There should be an ID number followed by the word device under List of devices attached, for example:

List of devices attached

12345c3006c0c721d0e     device

Now you are ready to remediate some nasties!

Removing DGBLuancher

Before we remediate DGBLuancher, be aware that DGBLuancher is the T95 TV box’s launcher app. A launcher app is the app used to launch and run everything on an Android device. For example, all your app icons, widgets, clock, getting to Settings, etc. Which leads me to this warning:

Uninstalling DGBLuancher without first installing another launcher to replace it will render the Android device useless.

The good news is that you can still use adb to send commands even without a launcher. So, make sure to set that up first.

You can use whatever TV launcher you decide. There are many good choices on Google Play to choose from.  Personally, I just chose the first one on the list, which happened to be ATV Launcher. As long as it’s malware-free, anything is better than DGBLuancher!

But before we begin, a disclaimer is necessary:

Proceed at your own risk! Neither I, nor Malwarebyes, can guarantee this will not damage your Android device and we accept no responsibility if it does. By proceeding, you take the risk and responsibility upon yourself.

Now usually, I would highly recommend using Google Play to install apps instead of a third-party app store. It gives you have the added protection of Google Play Protect, and it also ensures the app will work with your make, model, and OS version. However, since this was a preinstalled, malware-infested TV box that was already rooted, that was bought for around $30 on Amazon… you may choose to make an expedient exception this one time.

The options are:

1. Connect the TV box to the Internet to download a TV launcher from Google Play, whilst letting the malware do nasty things in the meantime.
2. Download a TV launcher from a third-party app store, such as ATV Launcher form APKPure, and then drag-drop it to the Downloads folder on the TV Box. Then install it from the FileManager app already on the TV box. All while not opening up the flood gates to malware-riddled network traffic.

Re-read that disclaimer above and make a decision you’re willing to take full responsibility for, then proceed.

Now that you have another TV launcher installed, you can now remove DGBLuancher using the following adb command:

adb shell pm uninstall -k --user 0 com.swe.dgbluancher

If, for whatever reason, you need to revert to DGBLuancher, here’s the command:

adb shell pm install -r --user 0 /system/priv-app/Launcher10/Launcher10.apk

Note that the above pm uninstall  command uses

-k

to quote “keep the data and cache directories around after package removal”, and --user 0 to only uninstall for the current user. Therefore, it is a safer method to uninstall system level apps because you can reinstall from the APK stored in the system folder.

At this point, it is a good idea to restart the TV box. With DGBLuancher now uninstalled and a new launcher running, Corejava classes.dex is neutralized. You can now use the box safely. But if you’d rather be safe than sorry, you can move on to removing Corejava for good.

Removing Corejava

A big shout out to Daniel for providing this clever method of removing and stopping Corejava from being created again in his cleanup script!

First, you need to gain root access:

adb root

Now, enter shell:

adb shell

From shell, check to confirm that Corejava exists (the output will tell you):

If you get output, “You are infected with Corejava!!!”, then move on to the removal process. That starts with removing /data/system/Corejava/ and anything in it:

rm -rf /data/system/Corejava

Now that it’s gone, we need to stop it from every coming back. Using the command touch, create an empty file named

Corejava

in /data/system:

touch /data/system/Corejava

Next, change the permissions so nothing can modify it:

chmod 000 /data/system/Corejava

This last step is key. It uses the chattr command located under

busybox

, which holds common legacy Unix commands, to set the attribute to +i. Why? Because “a file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file’s metadata cannot be modified, and the file cannot be opened in write mode.” In other words, game over Corejava!:

busybox chattr +i /data/system/Corejava

With these settings in place, whenever the system tries to create /data/system/Corejava, it will be denied as seen in the output from

logcat | grep Corejava

run in shell:

FileUtils: Failed to chmod(/data/system/Corejava): android.system.ErrnoException: chmod failed: EPERM (Operation not permitted)

Adups

Adups and I have had a fiery relationship. We have crossed paths several times. This time though, I come to Adups’ defense. Not all Adups versions are malicious, and I see no malicious activity from the version on the T95 TV box.

Although the existence of it prompted me into wanting to analyze the T95 TV box, it was not the culprit this time. That being said, you can follow the Uninstalling Adups and other preinstalled malware via adb command line tool just to make sure you are free and clear of any future malware. With Adups’ shady past, it probably isn’t a bad idea. Just remember, Adups is the app used to update the system including security patches. Luckily, the tutorial will show you how to restore Adups in case you want or need to run an update.

“Budget” should not mean “malware”

Once again, thank you to Daniel Milisic for bringing this to our attention. I’ll end by saying buying “budget” should not mean “malware infested”, as we’ve seen disgustingly in the past. Especially when the device is bought through a reputable online store like Amazon. I hope this analysis will help others remediate this bad actor. Stay safe out there!

Samples

Malicious classes.dex file

MD5: F9802B1168D5832D32C229776CD9B9AA.

Malicious Launcher APK

Package Name: com.swe.dgbluancher
MD5: EB850022E4269BB1DAB9FC5D2B0B734F