T95 Allwinner T616 Malware Analysis · Cleanup

Does your T95 Android TV Box contain a folder named:

/data/system/Corejava

...and a file named

/data/system/shared_prefs/open_preference.xml?

Your T95 is infected with malware pre-installed, ready to do whatever the C2 servers decide. Yes, malware from Amazon straight to your door! If they insist on selling these devices they really should add an "Includes Malware" category in the Android TV section.

A few months ago I purchased a T95 Android TV box; it came with Android 10 (with working Play store) and an Allwinner H616 processor. It's a small-ish black box with a blue swirly graphic on top and a digital clock on the front. There's got to be thousands (or more!) of these boxes already in use globally.

There are tons of them available for purchase on Amazon and AliExpress.

This device's ROM turned out to be very very sketchy -- Android 10 is signed with test keys, and named "Walleye" after the Google Pixel 2. I noticed there was not much crapware to be found, on the surface anyway. If test keys weren't enough of a bad omen, I found ADB wide open over Ethernet and WiFi - right out-of-the-box.

I purchased the device to run Pi-hole among other things, and that's how I discovered just how nastily this box is festooned with malware. After running the Pi-hole install I set the box's DNS1 and DNS2 to 127.0.0.1 and got a hell of a surprise. The box was reaching out to many known, active malware addresses.

After searching unsuccessfully for a clean ROM, I set out to remove the malware in a last-ditch effort to make the T95 useful. I found layers on top of layers of malware using tcpflow and nethogs to monitor traffic and traced it back to the offending process/APK which I then removed from the ROM.

The final bit of malware I could not track down injects the system_server process and looks to be deeply-baked into the ROM. It's pretty sophisticated malware, resembling CopyCat in the way it operates. It's not found by any of the AV products I tried -- If anyone can offer guidance on how to find these hooks into system_server let me know.

The closest I could come to neutralizing the malaware was to use Pi-hole to change the DNS of the command and control server, YCXRL.COM to 127.0.0.2. You can then monitor activity with netstat:

netstat -nputwc | grep 127.0.0.2

tcp6   1    0 127.0.0.1:34282  127.0.0.2:80     CLOSE_WAIT  2262/system_server  
tcp    0    0 127.0.0.2:80     127.0.0.1:34280  TIME_WAIT   -                   
tcp    0    0 127.0.0.2:80     127.0.0.1:34282  FIN_WAIT2   -                   
tcp6   1    0 127.0.0.1:34282  127.0.0.2:80     CLOSE_WAIT  2262/system_server  
tcp    0    0 127.0.0.2:80     127.0.0.1:34280  TIME_WAIT   -                   
tcp    0    0 127.0.0.2:80     127.0.0.1:34282  FIN_WAIT2   -                   
tcp6   1    0 127.0.0.1:34282  127.0.0.2:80     CLOSE_WAIT  2262/system_server  
tcp    0    0 127.0.0.2:80     127.0.0.1:34280  TIME_WAIT   -                   
tcp    0    0 127.0.0.2:80     127.0.0.1:34282  FIN_WAIT2   -                   
tcp6   1    0 127.0.0.1:34282  127.0.0.2:80     CLOSE_WAIT  2262/system_server  

I also had to create an iptables rule to redirect all DNS to the Pi-hole as the malware/virus/whatever will use external DNS if it can't resolve, and then tries with a nonstandard port.

adb shell iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 127.0.0.1:53
adb shell iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 127.0.0.1:53
adb shell iptables -t nat -A OUTPUT -p tcp --dport 5353 -j DNAT --to 127.0.0.1:53
adb shell iptables -t nat -A OUTPUT -p udp --dport 5353 -j DNAT --to 127.0.0.1:53

By doing this, the C&C server ends up hitting the Pi-hole webserver

1672673217|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673247|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673277|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673307|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673907|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673937|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673967|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0
1672673997|ycxrl.com|POST /terminal/client/eventinfo HTTP/1.1|404|0

"Stage 0" hooks system_server and attempts to pull-down a payload from ycxrl.com, cbphe.com, or cbpheback.com

The DNS addresses above (as of this writing) are hosted by Linode/Akami.
If this concerns you, consider reporting abuse to Linode at https://www.linode.com/legal-abuse as I have tried.

Cleanup Instructions

• Reboot into recovery to reset the device or use the Reset option in the 'about' menu to "Factory Reset" the T95
• When device comes back online, connect to adb via USB A-to-A cable or WiFi/Ethernet
• Run the script (WiP!)

Check if the script was successful

adb logcat | grep Corejava

The script prevents a successful download from the C2 servers, as the malware can't write to it's predefined location, preventing any payload from doing naughty things on your device:

101-10 23:34:39.759 2153 2153 W FileUtils: Failed to chmod(/data/system/Corejava): android.system.ErrnoException: chmod failed: EPERM (Operation not permitted)

01-10 23:34:39.760 2153 2153 W FileUtils: Failed to chmod(/data/system/Corejava/node): android.system.ErrnoException: chmod failed: ENOTDIR (Not a directory)

Ongoing Investigation

In this repo you will find Classes.dex, the 'Stage 1' payload I managed to capture. The malware takes many measures to prevent from being discovered. You can install Pi-hole and tcpflow to monitor activity. Hopefully a method can be found to to completely disable the malware, for the time being this is as close as it gets.