Validating The Digital Supply Chain
For more insights on hardware hacking, check out the webinar: Spooky Experiments – Building Your Own Security Research Lab.
With the help of the Eclypsium research team (and others mentioned below), I set out to look inside some of the Android TV devices on the market today. In 2023 in particular there have been many publications pointing out that Android TV devices come pre-installed with malware. It should be noted that the process and the findings below serve two purposes:
- Describe the process for validating the digital supply chain of devices so others can also learn and replicate on their own.
- Underscore just how difficult it is to validate the digital supply chain manually and without cooperation from all entities in the supply chain.
Attacking The Supply Chain With Pre-0wned Devices
Supply chain threats come in many different forms, including attackers placing malware and/or backdoors inside firmware or software at some point in the process before the device is acquired by the end-user or organization. Android devices serve as a great example of this type of threat. Previous research has observed several different manufacturers and threat actors specifically targeting Android TV devices (though some of the same malware can also be found in other Android devices, such as phones and tablets). The root of the attacks likely stems from the process of getting an inexpensive device to the Android TV market. As some suggest, there are base versions of Android and Android apps that are used on Android TV devices that have malware and end up in the hands of consumers, in some cases I believe without the intermediate manufacturers even knowing they contain malware. I’ve also observed situations where manufacturers are likely aware that applications included on the device contain malware, and may even conspire with malicious app developers to offer software updates. This means at any point a device may be “clean”, but subsequent updates to seemingly benign apps come loaded with malware. I also believe that we’re in a cat-and-mouse game with malware authors. As they tear down and rebuild, the IoCs change, making them more difficult to detect. There are also theories that there is cooperation between parties to ensure that malicious software to generate ad revenue is placed on Android TV devices, allowing them to be sold at more affordable prices (however, in this scenario your data is the product being collected and sold) Suffice it to say, be aware if you are shopping for Android TV devices.
As an exercise, we analyzed a few different models of Android TV devices and checked them against existing research (highlighted in the next section). The goal of this post is to document the process so people can validate their devices and ensure they are not “pre-0wned”.
History of Android TV Pre-0wned Devices
One of the things that led me down the path of exploring Android TV malware is the re-occurrence of the headlines warning people of the dangers of these types of devices. Below are some highlights:
- 2017 – It started with ransomware being discovered on Smart TVs (thankfully this did not take off). This particular type of malware seemed to be short-lived, infecting consumer Smart TVs, locking them up using a “screen locker”, and displaying a message to the user that they must pay a ransom if they want to use their TV again. In 2017 several different strains of Android malware, such as CopyCat, were infecting devices, mostly phones at this point in time. I also traced back a suspicious Android app that has gone through phases of being malicious; being labeled as benign, then back to malicious called “Adups”. I discovered newer versions of Adups on some of the devices we analyzed, noting that while they may not appear to be malicious at this point in time, they could auto-update and become malicious. This is especially concerning as most Android TV devices do not come with protections or detections for such threats.
- January 2023 – Thanks to independent research, and further analysis from MalwareBytes (and others), the T95 Android TV device was identified as hosting several different malicious apps. Security researcher Daniel Milisic created a Github repository that serves as an excellent point of reference to both identify malware on these devices and clean your device if it has been infected. This research also points to CopyCat as the malware (or variant) that was deployed.
- April 2023 – The popular YouTube channel Linux Tech Tips (LTT) published a video with similar findings as the research from January 2023. The LTT research was shared with Daniel Milisic for validation.
- May 2023 – The EFF issues a report stating “Certain Android TV Box models from manufacturers AllWinner and RockChip, available for purchase on Amazon, come pre-loaded with malware from the BianLian family, a variant of which we investigated last year.”
- In this very same timeframe, TrendMicro issued a report on Android malware it dubbed Lemon, stating: “We identified some of these businesses used for different monetization techniques, such as heavy loading of advertisements using the silent plugins pushed to infected phones, smart TV ads, and Google play apps with hidden advertisements.”
- September 2023 – An article was published by Dr. Webb that caught my attention and highlighted Android TV-based malware (with malware origins, in this case, tracing back to Mirai).
- October 2023 – Human Security releases a research report detailing Android TV analysis, including the identification of two new strains of discovered malware dubbed “Badbox” and Peachpit”. For good measure, Wired runs an article on the dangers of Android TV devices with backdoors.
Why Target Android TV Devices?
Attacking Android TV boxes provides attackers with certain advantages. The advantages below are also ubiquitous in nature across other platforms found in enterprise computing (including UEFI, BMCs, and network devices):
- Stealth – If the malware can be embedded early in the manufacturing process it can go unnoticed for some time. Most consumers do not run anti-malware software on Android TV devices, nor do they bother to look and check the supply chain and/or security of the devices.
- Persistence – Android TV devices by nature are connected to the Internet as the primary goal is to stream TV and movies. The Android applications can then automatically update and/or pull down more malware onto the systems at any time.
- Ubiquity – There are hundreds of choices for Android TV boxes, at very reasonable prices. This means the attackers can cast a wide net by pre-infecting various models, ending up in the homes of thousands of users across the globe.
Analyzing Android TV Devices
After hearing and reading about Android TV devices being pre-installed with malware, I wanted to see for myself. I mentioned my curiosity about Android TV devices to the Eclypsium research team and they too were intrigued and even joined in on some of the fun (along with my good friend Larry Pesce at Finite State). Several of us purchased at least one of the following devices:
Most research papers and articles I’ve read skip right to the Android malware they found on these devices. In this article, I’d like to walk you through how to approach evaluating the security of hardware devices so you can apply this knowledge to any related project, including checking your own Android or other such devices for evidence of pre-installed malware.
The ONN Android TV 4K
The first task is to take apart the device and expose the electronics. As you can see in the above image this device was not intended to be user serviceable as there are no exposed screws (or any screws underneath the sticker containing the model and serial numbers). Before I do any tinkering with the software, I like to know what I’m working with. Specifically, I like to see if there is a header available for either UART or JTAG. This provides some level of diagnostics, and potentially recovery if something goes wrong. While there are specialized tools for popping open the plastic cases I prefer my super-dooper-leet-reverse-engineering tool:
I used this tool on the ONN Android TV device to not only remove the board from the plastic case but also remove all of the heat shielding (that thankfully was not soldered or glued in place, which is sometimes the case).
To get more information about the components, I uploaded the photos to Google Photos and used the “Copy text from image” feature to provide me the text to copy and paste into Google and find more information, such as the specifications for the eMMC chip. I also identified the UART header and soldered on a pin header for access to the serial console.
It turns out that access to the Android debugger on the ONN Android TV device was limited to non-root access out-of-the-box. This means I could use the Android Debugger (adb) shell to gain access, but unable to perform a full analysis of the file system and look for indicators that have been previously published (or discover new ones) as permissions were limited. I tried, unsuccessfully, to root the Android device by several different mechanisms, and managed to corrupt the boot loader and was left with a device that only booted to a splash screen that displayed “ONN”. This is fairly common when doing this type of work, and I definitely learned the hard way that having more than one of the same device is helpful in this situation. Not wanting to end up with the world’s largest Android TV device collection, I proceeded with further hardware analysis.
Since my goal was to review the file system (not caring about getting Android root like many on the Internet that use this level of access to customize the device, remove spyware and malware Android apps, and remove apps that you are unable to remove via the Android TV interface), it was time to remove the flash storage (eMMC) chip. Once the chip is removed it can be read with an eMMC flash reader (such as this one: Rakstore EMMC153 EMMC169 Test Socket USB Reader). With the assistance of Larry Pesce (Product Security Research and Analysis Director at Finite State), a hot air rework station, and some desoldering wick, we successfully removed the chip (this is the easier part, re-installing the chip on the board is the really tricky part). We managed to dump the contents of the eMMC chip, however, the file system was encrypted. While further analysis is required to unlock the file system for this particular device I turned my attention to the other devices. If findings are produced from further research I will post a follow-up article sometime in the future.
The “Magiccube”
The same process was followed for the Magiccube device as we did for the ONN Android TV (eMMC was removed and placed in a reader and file systems were copied). The filesystem was not encrypted on this device, allowing for offline analysis. I mounted the file system using the following Linux commands (sdb25.img was the user data partition from the eMMC flash):
First, verified the file system, in this case it was ext4:
$ sudo parted sdb25.img print Model: (file) Disk /home/paulda/src/magiccube/sdb25.img: 27.6GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 27.6GB 27.6GB ext4
Next, run kpartx to map the file system dump to a loop device (required for mounting):
$ sudo kpartx -a sdb25.img
Next, mount the partition to a directory:
$ sudo mount -o loop,rw /dev/loop0 sdb25
I did not find any of the previously documented IoCs on the file system (e.g. there was no “Corejava” directory). I did run some of the Android apk packages through VirusTotal to see if I could find anything suspicious. One package, com.apkpure.aegon, clearly contained some sort of ad tracking. I also found some of the URLs below on a few different ad-blocking deny lists:
Having not found direct evidence of malware, I moved on to the next device.
The T95
The T95 Android device came with a version of Android that allowed us to use the Android Debugger (adb) as root over the network, retrieve files, and effectively hunt for malware. I did observe some unique behavior with the T95: after I enabled debugging, and then rebooted, I could not connect over the network to the adb service on TCP port 5555 unless I went into developer settings and enabled USB debugging (then it proceeded to listen on port 5555). I then connected as follows:
$ adb connect 192.168.1.150 connected to 192.168.1.150:5555 $ adb devices -l List of devices attached 192.168.1.150:5555 device product:walley model:MBOX device:walleye transport_id:1 $ adb shell walleye:/ $ $ adb root restarting adbd as root $ adb shell walleye:/ #
The following command allowed me to dump a list of installed packages as I was looking to match these to known IoCs:
$ adb shell pm list packages -f package:/system/app/TvdVideo/TvdVideo.apk=com.softwinner.TvdVideo package:/system/priv-app/CtsShimPrivPrebuilt/CtsShimPrivPrebuilt.apk=com.android.cts.priv.ctsshim package:/system/priv-app/GoogleExtServices/GoogleExtServices.apk=com.google.android.ext.services package:/data/app/com.google.android.katniss-cge_xXeW17WhrGeW3nufDg==/base.apk=com.google.android.katniss package:/system/priv-app/TelephonyProvider/TelephonyProvider.apk=com.android.providers.telephony package:/system/priv-app/DynamicSystemInstallationService/DynamicSystemInstallationService.apk=com.android.dynsystem package:/system/priv-app/CalendarProvider/CalendarProvider.apk=com.android.providers.calendar
While several of the Android packages and network traffic from this device were suspicious, I traced it back to references to adware. The “Walleye” reference is from the Pixel 2 version of Android, and this device also contained some test keys. I did not find any direct evidence of malware that previous researchers have found on the T95. My guess is that this device has a newer build that has removed traces of the previously discovered malware.
The X88 Pro 10
The X88 Pro 10 is similar to the other models that have been analyzed, with the exception of the SD Card reader. I discovered the article TV-box mania: X88 PRO 10 (RK3318) contained a tutorial that allowed for the device to boot a version of Linux directly from the SD card and contained a menu system that allows you to dump the contents of the onboard eMMC storage to the SD card. In the context of the tutorial, this was to create a backup. For our purposes, we can use the backup to perform analysis, a little easier than de-soldering and also preserves the device. I was able to carve out the user data partition from the image using the following process:
First, I printed out the partition in the image dump file:
$ sudo parted x88pro10.img print Model: (file) Disk /home/user/src/x88pro/x88pro10.img: 15.8GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name 1 8389kB 12.6MB 4194kB uboot 2 12.6MB 16.8MB 4194kB trust 3 16.8MB 21.0MB 4194kB misc 4 21.0MB 25.2MB 4194kB dtbo 5 25.2MB 26.2MB 1049kB vbmeta 6 26.2MB 93.3MB 67.1MB boot 7 93.3MB 97.5MB 4194kB security 8 97.5MB 198MB 101MB recovery 9 198MB 601MB 403MB backup 10 601MB 1003MB 403MB ext4 cache 11 1003MB 1020MB 16.8MB ext4 metadata 12 1020MB 1021MB 1049kB baseparameter 13 1021MB 1038MB 16.8MB logo 14 1038MB 4301MB 3263MB super 15 4301MB 15.8GB 11.5GB f2fs userdata
Next, I used sfdisk to get the offsets:
$ sfdisk -d x88pro10.img label: gpt label-id: 035B0000-0000-4C35-8000-04110000586F device: x88pro10.img unit: sectors first-lba: 34 last-lba: 30777310 sector-size: 512 <snip> x88pro10.img15 : start= 8400896, size= 22376415, type=1D0B0000-0000-453D-8000-2D3300005371, uuid=87340000-0000-4F30-8000-48C9000041B0, name="userdata"
Segment 15 contained the user data, taking the offsets and multiplying them by 512 produces the sectors needed to mount just that segment:
$ echo $((8400896 * 512)) $((22376415 * 512)) 4301258752 11456724480
Next, mount the partition with the specified offsets:
$ sudo mount -o loop,offset=4301258752,sizelimit=11456724480 x88pro10.img userdata
However, this process also produced an encrypted file system as you can see below:
As it turns out, I should have looked at using the Android debugger (adb) first! For reasons I have not yet determined (could it be a firmware update that blocked this?) I could not connect to the Android debugger over the network. However, I connected a USB 2.0 cable (USB-A to USB-A 2.0 cable) and was able to interact with the Android debugger via USB. I can confirm that this model does have indicators that it has been pre-infected with malware. Since the C2 infrastructure had been dismantled at the time of this writing, the next stage of payloads was not delivered to the device. I did find evidence of malware that matches previous analysis, including:
- Both the /data/system/Corejava directory and a file named /data/system/shared_prefs/open_preference.xml were present on the system
- The /data/system/Corejava directory only contained a file named “e.l” and an empty subdirectory called “node”
- When the device boots up, it attempts to resolve one of the domains used to get the later staged payloads called “cbphe.com”. Since this domain no longer resolves, it is unable to complete the malware infection.
This does not mean that we are in the clear. At any time the C2 could come back to life and re-infect this device. There is also some process that is triggering the stage 0 payload to attempt to pull down the remaining malware. Previous researchers have traced this back to a process called “system_server”, and at this time no further analysis or answers could be found in my research. Daniel Milisic states this in his write-up: “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.”
At this point, if we were to continue to use the device, I recommend it be wiped clean and run Linux (as described above) or use the clean-up scripts from Daniel Milisic.
Conclusion
Hunting for supply chain threats is tricky business and time-consuming. Most users may not go through the trouble of analyzing their devices to make sure it is not pre-infected during the manufacturing process. This does not only apply to Android TV devices since all the devices we use (personally and in the enterprise) could have similar supply chain security issues. While security researchers are working tirelessly to identify these threats, attestation of hardware and software during the manufacturing process would help identify these issues before they reach the consumer. Of course, the companies involved in the production of these devices would have to participate in such programs, validating and attesting to the security as they go. Thankfully there are third parties, such as ourselves, that are working every day to provide insights into the device supply chain and identify vulnerabilities and threats, hopefully before they have a negative impact.
Resources and References:
- ONN 4K Box https://www.exploitee.rs/index.php/ONN_4K_Box – This page offered up some tips on analyzing this particular device, however, I believe it was an older hardware model than the one we recently acquired.
- Rooting an ONN 4k – https://github.com/amit-raut/Onn.-4k-Streaming-Box-Rooting-and-Remote-Button-Remapping/blob/main/README.md – I just want to point out that this did not work on the newer ONN 4K device, essentially I bricked it trying to follow this guide. Consider yourself warned!
- T95 Android TV (Allwinner H616) includes malware right out-of-the-box https://www.reddit.com/r/Android/comments/101k0eg/t95_android_tv_allwinner_h616_includes_malware/ – A detailed account from a Reddit thread.
- Mirai variant infects low-cost Android TV boxes for DDoS attacks https://www.bleepingcomputer.com/news/security/mirai-variant-infects-low-cost-android-tv-boxes-for-ddos-attacks/ – Bleeping Computer coverage of the Human Security research.
Special thanks to the entire Eclypsium research team and Larry Pesce who assisted me with this research.
Tools and Commands TL;DR
This section is a quick recap of commands and tools used in the blog.
sudo parted sdb25.img print
- sudo: Run the command with superuser privileges.
- parted: A Linux utility used to manipulate disk partitions and view partition tables.
- sdb25.img: Specifies a disk image file that parted will operate on.
- print: Displays the partition table of the specified disk image.
sudo kpartx -a sdb25.img
- kpartx: A tool that’s part of the multipath-tools suite, used to create device mappings for the partitions of a device or a disk image.
- -a: This option tells kpartx to add mappings.
- sdb25.img: This is the disk image file for which you want to create partition mappings.
sudo mount -o loop,rw /dev/loop0 sdb25
- mount: A Linux utility used to mount file systems.
- -o loop,rw: Specifies mount options.
- loop: Indicates that the file/device should be mounted as a loop device. This is typically used to mount image files directly.
- rw: Mount the file system with read-write access.
- /dev/loop0: Represents a loopback device. These devices are used to mount file systems that are not associated with a physical device like disk images.
- sdb25: Specifies the mount point, which is the directory where the file system will be accessible once mounted.
adb connect 192.168.1.150
adb devices -l
adb shell
adb root
adb shell
adb shell pm list packages -f
- adb: Android Debug Bridge, a tool used for communication with Android devices.
- connect: Connects the ADB service to an Android device or emulator using a specified IP address.
- devices: Lists all connected Android devices and emulators.
- -l: Provides a long listing, offering more detailed information about each device.
- shell: Opens a command-line interface on the connected Android device or emulator.
- root: Restarts the ADB daemon with root privileges on the connected device, allowing elevated permissions.
- pm: Package Manager command-line tool.
- list packages: Lists all packages (apps) installed on the device.
- -f: Shows the associated APK file for each package.
sfdisk -d x88pro10.img
- sfdisk: A Linux utility used for displaying and manipulating partition tables.
- -d: Dumps the partition table in a format that can be used as input to sfdisk for replication.
- x88pro10.img: Specifies a disk image file that sfdisk will operate on.
echo $((8400896 * 512)) $((22376415 * 512))
- echo: A command used to display messages or output.
- $((…)): Arithmetic expansion syntax in the shell, which evaluates the arithmetic expression inside the double parentheses.
- 8400896 * 512: Multiplies 8400896 by 512.
- 22376415 * 512: Multiplies 22376415 by 512.
