If you searched “is my Android TV box infected?”, the useful starting point is a model lookup followed by checks on your particular device. A product name alone cannot answer that question.

Our XCPE checker searches a versioned copy of Synthient’s public model list. It runs locally in your browser. It does not connect to your TV box or inspect your network.

The quick answer

There are three different questions to keep separate:

  1. Was this model name observed in the research? The checker can help answer this.
  2. Does my particular box show suspicious indicators? Your device details and logs can help you investigate.
  3. Is the device clean and safe to keep using? A browser-based model lookup cannot establish that.

“Listed” is not a diagnosis. “Not found” is not a clean bill of health. Similar model names should be treated as suggestions until you verify the full spelling and suffix.

What Google reported about XCPE

On November 2, 2026, Google reported disruption of XCPE, a backdoor enrolling more than 1.3 million set-top boxes. It attributed the operation to Videostrong with high confidence and described affiliate activity including advertising fraud, residential proxies and additional malware delivery. These are attributed findings from Google Threat Intelligence Group’s report, not conclusions made by this website.

Google’s separate estimate of at least 10 million additional compromised devices concerns disruption of affiliate infrastructure with distribution channels beyond XCPE. It is not a count of devices covered by our model lookup.

Find the exact model and build

On the box, look under Settings → About or Settings → Device Preferences → About. Menu names vary. Write down the model and firmware build exactly as shown. Compare them with the underside label and your order details.

Keep suffixes such as PRO, PLUS and MAX. Do not substitute the brand name for the model. A retail name and Android’s reported model string can differ, so record both when available.

Enter the complete name in the model checker. Formatting differences such as spaces, underscores, hyphens and letter case are normalized. The result preserves the original strings from the source.

For example, searching KM9PRO finds a model string in the research. Searching for another member of the KM9 family is a separate lookup. A match for one name does not extend to every product with a similar name.

If the checker asks for more detail, inspect the device again. Very short or generic names may not distinguish one product or firmware from another. If the box reports only a generic name, record that limitation rather than guessing.

Check Pi-hole or router DNS logs

Start by finding the TV box in your router’s connected-device list. Note its local IP address and, when available, its MAC address. If the address has changed, make sure historical logs still refer to the same device.

For Pi-hole:

  1. Open the administration interface and select Query Log.
  2. Filter by the TV box’s client IP or client name.
  3. Search the relevant time range for anyevonline.com and szbboys.com, including their subdomains. The interface may require a partial-name search or separate searches for each host.
  4. Record the requesting client, complete hostname and timestamp. Check whether the entry represents a request, a blocked request or an allowed response.

On a router, look for DNS query logs, security logs or connection history. Some consumer routers offer no historical DNS logging. An empty screen in that case tells you little about past activity.

Google identifies infrastructure including mqtt.szbboys[.]com and ott.szbboys[.]com, as well as bootstrap hosts under anyevonline[.]com. Here, [.] means a normal dot; the notation avoids creating an active link. See the original report’s infrastructure and IOC sections.

DNS logs contain hostnames, not destination ports. Searching a DNS query log for ott.szbboys.com:8000 can miss the hostname. Use a connection or firewall log if you need to inspect a port.

A lookup attributed to your box warrants investigation, but DNS alone does not demonstrate successful malware execution or continuing attacker control. Also exclude requests from another device, such as a computer being used to research the incident. Do not visit the indicator domains to “test” them.

No results can reflect disabled logging, expired history, a different DNS resolver or a limited observation period. Do not reconnect a suspect device just to generate new logs.

Optional: read device details with ADB

This step is for readers who already use Android Debug Bridge and can authorize a connection to their own device. The web checker does not need ADB access. These commands only read information:

adb shell getprop ro.product.model
adb shell getprop ro.build.display.id
adb shell pm list packages x.cpe
adb shell pm list packages com.oemservice
adb shell pm list packages com.abc.nexus

The three package names are indicators described in Google’s analysis. Check for the exact lines package:x.cpe, package:com.oemservice and package:com.abc.nexus. Package filtering can also return longer names containing the text you entered.

If ADB reports an unauthorized connection, missing device or permission error, the check did not complete. An error is not a negative finding. Missing names also cannot exclude other variants or other unwanted software.

Keep debugging access private. If you enabled debugging for this inspection, disable it and revoke debugging authorizations afterward. No rooting, firmware flashing or package deletion is needed for these checks.

Decide what to do next

Only a model match: verify your full model and build, review available logs, and contact the seller or manufacturer with the details. Ask whether their response applies to your exact device and firmware, rather than the brand generally.

Suspicious device or log evidence: our precautionary recommendation is to disconnect the box from the network while investigating. Preserve a short record of what you observed. Ask the seller for a documented remedy, return or replacement. If you need help interpreting evidence, consult someone qualified to inspect the device.

No match or insufficient records: document the limits of your checks. Use official update channels and seek support if the origin or maintenance of the firmware is unclear. Avoid treating the result as a reason to install an unknown “cleaner” APK.

These practical recommendations are aluo.app’s guidance. They are not a device-specific remediation procedure issued or approved by Google or Synthient.

Does the takedown make the box safe?

Google describes the backdoor as persistent in firmware and able to reinstall after reboot. Disrupting control infrastructure therefore does not demonstrate removal from an individual device. See its malware overview.

We do not promise that a factory reset, uninstall or domain block makes a box clean. Likewise, we cannot predict whether a particular box will continue playing media after the disruption. Playback and connectivity are separate observations from firmware integrity.

Ask a support provider what has actually been verified: which hardware revision, which build, which remedy and what evidence of resolution. Until that is clear, “it still works” and “the domains are blocked” leave the underlying question open.

How the checker is maintained

The model list comes from Synthient’s public research repository. The tool links to the immutable source revision used for its snapshot, preserves original spelling and displays separate data-retrieval and editorial-review dates.

An update to the source does not automatically change this website. Model data and guidance need review before publication. This project organizes public evidence; it does not test every listed product or certify any device.

Open the XCPE model checker to search the list and use the compact verification checklist.