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 CopyCatin 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 came 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.
- 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
adbvia USB A-to-A cable or WiFi/Ethernet - Run the script (WiP!)
adb logcat | grep Corejava
The script prevents a successful download from the C2 servers, as the malware can't write to /Corejava, preventing the 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)
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.