Some observations regarding T95/Malware

[parallyze]

Hi all,

rather new to Android devices I came across DesktopECHOs interesting findings. And because I'm new to Android I thought I'd have a closer look. I'd just like to share some observations I made while digging through some of the ROMs that are to be found on the interwebs:

T95-H616-X29, the X30 OTA-Update and an older -A27 release are the ones I've been playing around with.

Observations:
Doing the suggested things (chmod/chattr etc.) does prevent the Corejava directory from being created. But another thing caught my attention which I haven't seen mentioned:

There's always a service running called "IPlugManager" which I couldn't find meaningful information about. On the X29 firmware IPlugManager will always run with ID 1 after the 2nd boot (~12-14 when first booting after flashing). Using the A27 firmware the ID will vary, but usually it's < 5. So whatever "IPlugManager" is - it's loaded VERY early in the process.

Also I did see requests to one of the domains mentioned using tcpdump - so there's still unwanted activity, despite it being limited by the modifications to data/system/Corejava.

I then went ahead and removed as many packages from the ROM as I could. Another observation:
/product/priv-app/provision/provision.apk
That one somehow fiddles with permissions. If this one is removed you can not access the developer options any longer, even when using the root switch in settings -> device -> about.

And because it did sound interesting I read some articles about Copy Cat and the like. Which made me check /system/lib/libandroid_runtime.s0.

On A27 and X29 that one is > 1.6 MB, around 200k larger than the ones I found in other ROMs. But all the other libraries inside the directory seemed identical to other ROMs... so I replaced this one.

This finally had some effect. After flashing the firmware and on the first boot some process still tried to create the Corejava directory. But that does not happen any longer when rebooting - even if no /data/system/Corejava exists (file or dir) it won't be created again.
Edit: I made a mistake here, I was creating the file Corejava inside the /bin/preinstall script. After swapping the libandroid_runtime.s0 the Corejava directory is not created at all, neither on the first boot (preinstall) nor on subsequent ones.

Also the "IPlugManager" service is nowhere to be seen any longer.

Interesting differences I've seen on X29 vs X30 (released in April 2023):

• /system/bin/prebuilt now includes a rm -rf for shared_preferences and Corejava
• /system/lib/libandroid_runtime.so is ~200kb smaller

So I'm wondering if the attention in media made them modify and/or remove this from the X30 image.

Maybe somebody else can use any of this. But as I'm rather new to all this I might be on a completely wrong track the whole time.

Oh, another important note from my side: I do not own a T95 box. I've bought a "Q Plus / Q+ / QBOX" one recently and
couldn't find an Android 10 stock image. The T95 does work, but the FD655_Demo service needs to be stopped to avoid the RGB led flickering once a second...

And another important thing: Because this was quite time consuming I didn't test the X30 release. I've got only PhoenixSuit at hand which doesn't seem to support those OTA updates. So if anyone could confirm X30 being different after flashing, that'd be great ^^

Cheers,
Daniel

[parallyze]

Just a minor update, FWIW...

The images I found for the T95 (A27, X29, X30) all seem to be somewhat sketchy. Obviously almost all of these images for
those cheap boxes do, as stated multiple times. But the prepared libandroid_runtime.so is part of the Corejava/network activity things.

Replacing it does prevent the directories from being created, still there's stuff running in the background trying to do this all
the time. On X29/A27 I've seen some rather high cpu usage on ueventd (~8%) even when there wasn't anything going on at all.
Additionally X29 will spam the system log with VM crash logs, propably because it can't hijack libandroid_runtime.so as expected.

Then I remembered my other tv box I've bought a few weeks ago. It was sold as "X96Q" and is using a H313 SoC.

Flashing it directly did not work. But mixing the images (boot.fex etc. from the X29 one, some of the sunxi ir keylayouts and
the whole /vendor directory) did the trick. Of course I don't know if the image from the X96Q box is "clean" - but that's
hard to tell on any of them. At least it didn't create any of the mentioned directories from the start and the whole system
log looks way less messed up. Also I didn't see any unwanted network activity using tcpdump for ~30 minutes idling.

Another thing I couldn't get working: Properly updating gms/gsf/playstore. No matter what I tried, I ended up running into
well known problems (insufficient_space error when updating etc.) - even if there wasn't any of the components included while
flashing. I guess this all boils down to the rather complex permission system behind this. And seemingly all those apps that
come preloaded rely on some 3rd party service for updating.

Thankfully I'm not interested in running playstore etc., so I also removed any google apks included in the image. Just like most
of the included apks like emotn, droidlogic.xlauncher, dbg.sweluancher, adups and whatever. I did include flauncher 0.18 as a
default launcher and modified /bin/preinstall to set some basic settings (audio, timezone etc.), so for my needs everything
except a current release of kodi is now ready right after flashing, without the need to disable 30 packages or so.

For fun I checked some of the directories on virustotal. One of the reasons why all those "updated" firmwares probably never
update system components is the root access - all of them are using some kind of package to make this possible, so naturally
the "Provision.apk" and "AwProvision.apk" reported things like:

A27/X29/X30 image (T95-H616)
Provision.apk
Trojan/Android.HideIcon.1023644

X96Q image (2022-09)
AwTvProvision.apk
Android.PUA.DebugKey

libandroid_runtime.so included in A27/X29 reported:
Exploit.Enoket!8.439 (TFE:24:YYLeUVFZgDF)

Another difference between those images:
The T95 image is using apex/com.android.runtime.debug, while the X96Q one is using .release. Maybe this is the reason why
I think the box is running a bit "smoother" now.

But hey. While digging through this I also came up with a solution for another thing I don't like on these boxes: The missing
battery to keep the RTC running. Some of the boards do have solder pads for a battery holder - but there seems to be a PMIC
missing and without schematics it's impossible to tell if pin K6 from the SoC is connected.

So if you're like me and want one of those boxes to run completely offline but retain it's time, the workaround I'm using:
A Arduino Nano + DS3231 RTC connected to one of the USB ports, fetching time on each boot using stty.

bye,
Daniel