A few weeks back, Hackread.com reported about a malware-infected Android TV box available on Amazon: the T95 TV box. The box contained pre-installed malware, which was discovered by a Canadian developer and security systems consultant, Daniel Milisic.
Now the same TV box is in the news again, and the person who has identified security threats is Malwarebytes mobile malware researcher Nathan Collier. He purchased this device from Amazon to further probe and instantly realized something was off about this TV box. Collier discovered that regardless of whether the toggle switch was on or off, the box was rooted.
What is Rooting?
For your information, in an Android device, rooting refers to acquiring the highest level of access, aka root. It allows the user to modify system-level directories and files, which otherwise is not possible.
Developers require this heightened access to test the device in the pre-production phase. However, it must be noted that Android devices aren’t rooted during production. If the command adb (Android Debug Bridge) root is run on an under-production Android device, it will display the error “adb cannot run.”
Conversely, on a rooted device, the message appears as “restarting as root” or “adb is already running as root.”
Tools Used in the Research
Collier performed his research on the Android TV box using a few tools, including Android Debug Bridge from the Android Studio, Telerik Fiddler Classic internet traffic monitor with exceptional HTTPS capturing capabilities, NoRoot Firewall app that allows or denies network traffic as per an app’s requirement, and LogCat command line tool.
Performing the Research on TV95 TV Box
Collier hypothesized that DGBLuancher was responsible for APK loading and running Corejava classes.dex. To prove this hypothesis, Collier uninstalled DGBLuancher and kept Corejava classes.dex. The malicious traffic stopped immediately without DGBLuancher, Ergo, Corejava classes.dex cannot run.
Collier then reinstalled DGBLuancher, and this time he removed Corejava classes.dex, too, but again the malicious traffic stopped, and no new traffic was produced. This means the traffic required Corejava classes.dex to be produced. Hence, Collier concluded that the DGBLuancher was the APK loading Corejava classes.dex.
Later, Collier deleted Corejava classes.dex from the /data/system/Corejava, but it reappeared immediately after a reboot and when DGBLuancher was uninstalled Corejava classes.dex stopped reappearing. This strengthened the hypothesis that DGBLuancher was the culprit as it created Corejava classes.dex.
Now he had to find out why Corejva classes.dex reappeared. Collier learned that system_server ran more commands in the background than just create /data/system/Corejava. DGBLuancher used system_server to create Corejava classes.dex, so it wasn’t the culprit but conduit. Collier couldn’t determine why Corejava classes.dex reappeared.
How to Fix the Issue?
In a blog post, Collier recommends a factory reset before proceeding to fix the issue. A factory reset will remove the malware that might have been downloaded during this time. Afterwards, avoid connecting the box to a network until you install adb onto a Linux, Windows, or Mac environment and put the box into Developer Mode.
Turn on USB0 device mode to install adb. Connect your PC to the box, open a terminal such as Command Prompt on PC, and type: adb devices, which will display an ID number and a list of devices attached. Now you can remove the DGBLuancher. Check out Nathan Collier’s blog on Malwarebytes for a detailed remediation process.
