How to Analyze Android TV Box Traffic With Wireshark (vSeeBox Security Test)

Claude

I found nothing malicious in this capture. The onn 4K Pro (192.168.137.223) talks almost entirely to Google infrastructure, and the behavior fits a stock Google TV box streaming YouTube. There are a few minor network-quality issues, covered below.

What the capture contains

It’s about 62 minutes and 206k packets. The box is on the 192.168.137.x subnet, which looks like a Windows Internet Connection Sharing hotspot, with 192.168.50.1 as the upstream router. The box was mostly idle for the first ~14 minutes, then started streaming.

The big flow: 92.249.37.194

• It accounts for about 214 MB of the 230 MB total (roughly 93%), almost all inbound.
• It first appears at ~826 seconds, right after the box resolved manifest.googlevideo.com and rr#---sn-*.googlevideo.com. Those are YouTube video-delivery hostnames.
• The pattern is normal video streaming: about 243 short HTTPS connections, steady inbound bursts of 8–40 MB per 5 minutes, and only ~3.3 MB outbound, mostly TCP ACKs.
• That IP isn’t in a Google address block I recognize. That’s common for Google Global Cache servers hosted inside ISPs, but the CSV can’t prove who owns it. To confirm, run a whois or ASN lookup on it. You can also check that the same hostnames resolve to it when you query a public resolver like 8.8.8.8.

Everything else is ordinary Android TV / Google traffic

• Connectivity checks (connectivitycheck.gstatic.com, /generate_204) about once a minute.
• Google Play services and push (port 5228), the Android TV launcher and “dream” (screensaver) backends, the Assistant, Play Store, and SafeBrowsing.
• Firebase telemetry (app-measurement.com) and Google ad serving (pagead2.googlesyndication.com), likely for home-screen promos.
• mDNS/Chromecast advertisements (_googlecast._tcp), which is the built-in Cast receiver.

Things I specifically looked for and did not find

• No DNS lookups to unfamiliar or oddly named domains, and no DNS-over-TLS or DNS-over-HTTPS.
• No traffic on unusual ports. Everything is 443, 80, or 5228.
• No local-network scanning or connections to other LAN devices.
• No beaconing to non-Google hosts, and no large uploads.
• The only unencrypted HTTP is the connectivity checks and one POST /uma/v2 (Chrome/WebView usage metrics) to a Google host. It’s cleartext but low sensitivity.

Minor problems, not security ones

• MTU issues. The upstream router sent 38 “Fragmentation needed” ICMP messages, in bursts around 125s, 137s and 630s. That points to a path-MTU mismatch somewhere in the hotspot/router chain, which can cause stalls or retries.
• Some packet loss on the streaming path. There were 841 duplicate ACKs, 257 retransmissions (about 0.1% of packets), and 33 resets from the box to the streaming server. Resets like that are normal when a player switches quality or seeks. If you saw buffering, this is where I’d look.
• Connectivity-check resets. The 57 resets from 142.251.215.131 are the connectivity-check server closing connections abruptly, which is harmless.
• Harmless ICMP. The 5 “port unreachable” messages the box sent back to 172.217.117.4 were just leftover QUIC packets arriving after the app closed its socket.

Limits of this analysis

• Nearly everything is TLS 1.3 or QUIC, so I can only see who the box talked to, when, and how much, not the contents. The CSV also has no SNI or certificate fields.
• This hour looks like a fairly clean box with only YouTube in use. Sideloaded apps, a specific app launch, or scheduled tasks could behave differently, so a clean hour isn’t proof for the whole device.

Send over the second box’s CSV and I’ll run the same checks. I’ll also compare the two, including whether both are being served from the same 92.249.37.194 node.

Claude

The vSeeBox looks noticeably worse than the onn box. I can’t call it confirmed malware, but it has three behaviors I wouldn’t be comfortable with on a home network, and the payloads are encrypted or not visible in the CSV, so I can’t say what’s being sent.

A correction to my first report: I said the CSV had no SNI (server name) info. That was wrong. Wireshark puts it in the Client Hello lines. I re-checked the onn capture: 92.249.37.194 is named in the TLS handshakes as manifest.googlevideo.com and rr#---sn-*.googlevideo.com. That fits YouTube streaming from a cache node and supports my “benign” conclusion, though it’s still not proof of ownership.

What’s concerning on the vSeeBox (192.168.137.129)

1. It bypasses your local DNS with hardcoded public resolvers.
   • The box asks the gateway to resolve qd.pixleter.com and gets NXDOMAIN (“no such name”) every time.
   • At the same instant it opens HTTPS connections to four resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), Alibaba’s AliDNS (223.5.5.5) and DNS.SB (185.222.222.222). The timestamps line up to the millisecond. This happened at every reconnect, 9 times.
   • That pattern is a fallback resolver built into the firmware or an app. It’s the kind of design used to get around DNS blocking or filtering.
   • I couldn’t find any public information on pixleter.com, so I don’t know what it is. The DoH contents are encrypted, so I’m inferring the lookup target from timing.
   • NXDOMAIN could just mean the domain is dead, or that a DNS filter upstream of the Windows hotspot is blocking it. If you run one, that matters.
2. It runs an unencrypted remote-command channel to the vendor.
   • The domain is mqtttcp.vseeott.com, at 15.204.215.109 (a hosting-provider address; verify with whois).
   • It uses MQTT on plaintext port 1883 with a keepalive every 60 seconds.
   • On each connect the box publishes a 369-byte status message to t101/device/<device-id>/publish. The server immediately replies with two messages on .../cmd of 162 and 363 bytes.
   • The sizes are identical all nine times, so it looks like routine config or status pushes rather than one-off commands. But a vendor server that can push commands to your device, over an unauthenticated plaintext link anyone on the path could read or spoof, is a real risk.
   • In Wireshark, filter on mqtt and Follow TCP Stream to read what the box reports and what it’s told to do. That would settle this.
3. It talks to an unidentified third-party service.
   • The box holds a long-lived TLS session to weather.qstar.video (behind Cloudflare), re-established after each reconnect.
   • It’s probably a weather widget backend, but I couldn’t find public info on qstar.video either.

The rest of its traffic looks normal

• Google Play services push (mtalk.google.com), connectivity checks, Assistant and Play.
• Xiaomi’s connectivity check (connect.rom.miui.com, on Alibaba Cloud Singapore). This suggests the firmware is derived from Xiaomi/MIUI code, which is odd for a “vSeeBox” but not malicious in itself.
• It sent only ~790 KB in the whole hour, with no scanning, no LAN traffic to other devices, and no large uploads.

Reconnect churn: the box renewed DHCP 9 times (~81s, 284s, 1021s, 1190s, 1737s, 2035s, 2240s, 2400s, 2661s). Each time it repeated the whole routine: MQTT connect, pixleter lookups and the resolver bursts. That suggests it’s sleeping and waking, or the Wi-Fi link is dropping. Either way it re-announces itself to the vendor every time.

Side by side

What I’d do

• Put the vSeeBox on an isolated guest or IoT network with no access to your other devices.
• Block outbound MQTT (port 1883) and DNS-over-HTTPS to those four resolver IPs for this device, and force its DNS through your own resolver.
• Read the MQTT payloads as described above.
• Take a longer capture while you actually use its apps. This one was mostly idle, and behavior often changes once IPTV or sideloaded apps run.
• Check nslookup qd.pixleter.com 8.8.8.8 from your PC to see whether the domain exists at all. That’s a DNS query only, so it’s safe.

If you have the box’s model and firmware version, or a list of installed apps, send them over and I can narrow down where the DNS-fallback behavior comes from.

Claude

Each of these has an innocent explanation, so none is proof of anything on its own. They’re concerning because of what the behavior would allow if the vendor, or someone who compromised them, wanted to misuse it. I’d rank them 2, then 1, then 3.

2. Plaintext MQTT with server-pushed commands (most concerning)

• The vendor can reach into the box at will. The box opens the connection outbound, so your router and NAT don’t block it. Once it’s up, the server can send cmd messages whenever it likes. Each time the box connected, it got two replies (162 and 363 bytes) right away.
• I can’t see what those commands do. They might be harmless config or update pushes. But on a full Android device, a command channel can in principle install apps, change settings, or turn the box into something that proxies traffic. The only way to know is to read the payloads.
• It’s unencrypted. Anyone on the path (your ISP, a compromised router, a shared network) can read the device’s status reports. If the commands aren’t signed or authenticated, they could also inject their own. The status message includes a device ID, which leaks as well.
• The box sits on your LAN. A compromised or malicious command channel on a device inside your network is a bigger deal than the same thing on an isolated device.

1. Hardcoded DNS fallbacks that bypass your resolver (moderately concerning)

• DNS is a control and visibility point. Filters like Pi-hole, router parental controls and malware blocklists work by watching or answering DNS. A device that asks four public resolvers over HTTPS when your resolver says “no” defeats that blocking. It also hides what the box looks up from your logs, because it looks like ordinary encrypted web traffic.
• The domain is unidentified. The box was refused qd.pixleter.com and immediately tried harder to resolve it. If your upstream DNS was blocking it, the box was deliberately routing around the block. If the domain is simply dead, the box was just retrying, which is harmless. I couldn’t tell which.
• Innocent explanation. Plenty of apps and SDKs use DoH fallback for reliability, and the inclusion of AliDNS suggests a resolver list built for the Chinese market. So the mechanism alone isn’t damning. The worry is the intent it could serve.

3. The unidentified weather.qstar.video (least concerning)

• It’s an unattributed recipient. The box keeps a long-lived session to a domain I couldn’t identify, and Cloudflare hides who runs the origin server. Whatever the box sends there (your IP, rough location, device ID) goes to a party you can’t identify.
• Most likely it’s just a weather widget. The traffic volume was tiny. I’m flagging it mainly because I can’t attribute it, not because it did anything suspicious.

Why they matter together

Cheap Android TV boxes have a documented history of firmware-level problems, including pre-installed backdoors, which is why the FBI has issued warnings about them. I’m not saying your box is affected, and nothing here shows that. But a vendor-run command channel, a way to dodge DNS filtering, and endpoints nobody can identify are the pieces you’d expect to see in a box like that. That’s enough to justify isolating it while you find out more.

What would change my view

Reading the MQTT payloads in Wireshark (filter mqtt, then Follow TCP Stream) is the most useful next step. If the messages turn out to be things like “current firmware version” and “no update available,” this drops to “sloppy vendor security.” If they contain app lists, other devices on your network, or instructions to fetch and run something, that’s a very different situation.

Claude

That’s a fair reaction. Nothing in the capture shows what people usually fear from cheap Android boxes:

• No proxy or botnet behavior. Compromised boxes are often turned into residential proxies or ad-fraud bots, which shows up as lots of connections to odd hosts, or as steady traffic while the box sits idle. This one moved about 790 KB in an hour.
• No scanning, DDoS traffic or crypto-mining pool connections. There was also no probing of other devices on your network.
• Nothing unusual sent out. There were no large uploads and no long list of strange domains. Nearly everything went to Google, Xiaomi’s connectivity check, one vendor server and one Cloudflare-fronted endpoint.
• The command channel looks routine so far. Across nine check-ins over about 45 minutes, the server sent back the same two message sizes every time (162 and 363 bytes). If someone were actively tasking the box, I’d expect the messages to vary. This isn’t proof, since identical sizes don’t mean identical content, but it leans toward static config pushes.

So “worse than the onn, but not alarming” is my honest read of this data.

The reason I’d still stay cautious is how little this capture covers. It’s one hour of a mostly idle box, with none of its bundled apps running. Malicious firmware often stays quiet, activates on a schedule, or only acts once the box has been online for days. It also can’t show what’s in the encrypted traffic, or what the vendor’s server could send in the future. A clean hour tells you the box isn’t obviously compromised right now, not that the channel couldn’t be misused later.

Given that, I’d keep it on an isolated IoT or guest network and take two low-effort follow-ups:

1. Read the MQTT payloads. This is the most useful single step. If you paste the decoded text of one publish and the two cmd messages (redact the device ID and any MAC or IP), I can tell you what they do.
2. Capture longer while using it. A few hours or a full day, with the apps you actually use running, would show whether anything changes.

If both look boring, I’d treat it as a vendor with sloppy security practices, not a compromised box.

Claude

Yes, it could, in either direction, which is why I’d call this hour a baseline rather than a verdict.

What this capture represents

The traffic in it came from the operating system and the vendor’s firmware layer: Google services, the Xiaomi-derived connectivity check, the MQTT check-ins, the DNS fallback. That behavior runs whether or not you ever open an app, so leaving the apps unused doesn’t make those three items go away. The apps are a separate layer on top.

What using the apps could add

• Many more destinations. Streaming and live-TV apps typically contact lots of servers: content sources, CDNs, playlist and guide-data hosts, license or login servers. A quiet box turning into one with dozens of new domains isn’t suspicious by itself, but each one needs a look.
• Ad and analytics SDKs. Third-party apps often embed trackers that phone home with device identifiers, and on a cheap box the app selection tends to be less vetted than what’s in the Google Play catalog.
• Activation or account traffic. If an app needs a code or subscription, it will contact the provider’s servers, and anything you enter (email, password, payment info) goes through that app.
• Unknown providers. The vSeeBox is sold as an IPTV-style streaming box, and apps in that category often depend on third-party services that are hard to identify. I can’t tell from this capture which apps yours ships with or who’s behind them.
• The unidentified domains may start to make sense. qd.pixleter.com and weather.qstar.video could belong to a bundled launcher, widget or app. Seeing what they do when the matching app is opened would help attribute them.

What I’d do

1. Before launching anything, look at Settings ? Apps and note what’s pre-installed, especially anything unfamiliar. Disable or uninstall what you don’t need, and check the permissions on the rest.
2. Start a fresh Wireshark capture and open apps one at a time, jotting down the clock time each one launches. That lets me match traffic bursts to specific apps.
3. Send me the CSV and I’ll list the new domains and say which look like content delivery, telemetry or something I can’t place.
4. Keep the box isolated on its own network during this, and don’t enter real account credentials, especially payment or email logins, until you know what you’re dealing with.

If the apps introduce a long list of unrecognizable hosts, or the box starts generating traffic while you’re not using it, that would raise my concern a lot. If it just talks to normal content servers, I’d treat the picture as similar to what we’ve seen.

1. Start Wireshark before you power on or wake the box. That should catch the pixleter lookups, the MQTT connect and cmd exchange, and the SNI for 119.147.179.152, all of which were missing here.
2. Then open the apps one at a time and note the clock time each one launches. Even a few minutes of real use per app would be enough.
3. Export the CSV the same way, so the Client Hello lines keep their SNI.
4. If you can, also send the decoded MQTT payloads from the earlier capture. That remains the most informative single thing.

Claude

You need the original capture file (.pcapng), not the CSV. The CSV only keeps the summary line for each packet, not the message contents. If you’ve deleted the original, or your capture started after the box connected, you’ll need a new capture (step 1 covers this).

1. Get a capture that includes the MQTT connect. Open your original .pcapng if you still have it. Otherwise start a new capture on the hotspot interface, then power-cycle the box so it reconnects. The two command messages arrive right after it connects, and the session you captured last time never reconnected. To keep the file small, use the capture filter: host 15.204.215.109. Stop the capture after the box has been up for a minute or two, and save it as .pcapng.
2. Filter for MQTT. Type mqtt in the display filter bar at the top and press Enter. In the Info column you’ll see lines like Connect Command, Publish Message [t101/device/<device-id>/publish] and Publish Message [t101/device/<device-id>/cmd]. To show only the messages, use mqtt.msgtype == 3 instead.
3. Read one message directly. Click a Publish Message row. In the middle pane, expand MQTT and look for the Message field. Wireshark shows it as hex, with the decoded text next to it or below it. You can also right-click Message and choose Apply as Column, so the payload appears in the packet list for every publish.
4. Follow the TCP stream for the full conversation. Right-click any MQTT packet and choose Follow, then TCP Stream (Ctrl+Alt+Shift+T). A window opens with the whole session as text. Red is what the box sent and blue is what the server sent. Look at the two blue blocks right after the connect, which should be the 162-byte and 363-byte cmd messages, and the one red 369-byte status block.
5. Switch the view if it’s garbled. Use the Show data as dropdown at the bottom of the stream window. ASCII works for JSON or plain text. If it’s unreadable, try Hex Dump or Raw. Binary or scrambled data is a finding in itself, because it means the vendor is obscuring what the box sends or receives.
6. Redact and share. Before pasting, replace anything identifying: MAC addresses, the device ID in the topic, your IP, serial numbers, and any tokens, keys, Wi-Fi names or passwords. Keep the field names and structure intact, because those are what I need to see. Paste the three messages (the status publish and the two cmd messages) and I’ll go through them.

If the box is on the Windows hotspot, capture on the interface that carries the hotspot traffic (usually the “Local Area Connection*” adapter, or whichever one shows 192.168.137.x addresses). Otherwise Wireshark may see nothing from the box.

Claude

I decoded all three MQTT messages, and they’re benign in this session. They match the milder outcome I described: sloppy vendor security, not a remote-control channel.

How I got the contents

The payloads aren’t encrypted. They’re base64 with the text split and reversed, which is trivial to undo but unreadable at a glance. The connect packet and topic names are plain text.

What the messages say

Box ? server (the 369-byte status message):

{ "code": 10102001,
  "data": { "active": 1,
            "sn": "<32-char hardware serial>",
            "version": "14.5.1.168",
            "mac": "<your box's ID>",
            "board": "s4",
            "platform": "aospplus",
            "customer": "V6_MAX" },
  "time": <unix timestamp> }

Server ? box, message 1: {"code": 0, "data": {}}. This is an empty acknowledgement.

Server ? box, message 2 (the larger one): a list of two items, code 10101001 ? {"enable": true} and code 10101005 ? {"pass": true}. These look like license or feature-activation flags. The codes aren’t documented anywhere I could find, so that reading is an inference.

Nothing in them is an app list, a list of other devices on your network, Wi-Fi details, a URL, or an instruction to download or run anything.

What I’d still note

• The box registers itself in cleartext on every boot. It sends its serial number, MAC, firmware version and model over plain MQTT, so anyone on the path can read them. That’s a privacy and hygiene problem, not an attack.
• The MQTT login is also unencrypted. The connect packet sends the username (derived from the MAC) and a 32-character password in plaintext. Someone on the path could copy those credentials. I’m not repeating the password here.
• This is one 3-message session. The code field suggests the vendor has a larger vocabulary of messages, such as firmware updates. I can only vouch for what was sent during this boot, not what the server could send later.

What else the boot capture showed (106 seconds of traffic)

• A tidy startup sequence. In the first ~10 seconds after the network came up, the box contacted:
  • Google services and Xiaomi’s connectivity check
  • weather.qstar.video
  • datetime.mytv.xin, a plain-HTTP time sync that returns the current UTC time. Its URL includes a per-device ID, which is minor.
  • the MQTT server
  • api3.oplonx.com and asset3.oplonx.com, then cmsapi.vseeott.com
• One large download. About 2.8 MB came from asset3.oplonx.com in ~4 seconds. The names suggest launcher or home-screen content, but the traffic is encrypted, so I can’t confirm that. I couldn’t find public information on oplonx.com, qstar.video or mytv.xin. They appear alongside vseeott.com at boot, so they’re probably vendor infrastructure.
• The qd.pixleter.com lookups. They returned NXDOMAIN 20+ times in ~10 seconds, each time alongside a burst of connections to the four public DNS resolvers. No new server appeared after those bursts, so the domain may simply be dead. That’s a stale entry retried against every resolver it knows, not a deliberate bypass of your DNS. I can’t prove that.
• The unattributed IP. 119.147.179.152 from the last capture didn’t appear at all this time.

Updated view

• Item 2 (MQTT): much less worrying than I feared, though still a plaintext vendor channel.
• Item 1 (DNS fallback): less worrying if the domain really is dead. To check, run nslookup qd.pixleter.com 8.8.8.8 on your PC. If it also returns “non-existent domain,” that supports the dead-domain explanation.
• Item 3 (unidentified domains): still unattributed, but they look like vendor content services and not command-and-control.

I’d still keep the box on its own network segment and turn on Wi-Fi isolation if your router has it. If you use the apps, watch for sudden increases in traffic to the oplonx hosts. That’s where a change in behavior, such as an app or config download, would show up first.

Summary

TROYPOINT has never recommended these “loaded” Android TV boxes, and it isn’t just because of the background network traffic or potential malware threats. The core issue is the business model itself. These companies take cheap, uncertified hardware and mark it up to exorbitant prices, justifying the cost by promising “lifetime access” to live television and video-on-demand services.

However, in the cord-cutting world, “lifetime” only lasts until the manufacturer inevitably gets shut down, sued, or simply abandons their servers. When those streams go dark—as they always do—you are instantly left with an expensive $300 paperweight. You are far better off purchasing a premium, certified device, like the Walmart Onn 4K Pro or a BuzzTV G Series, and taking the time to learn how to set up the streaming applications yourself for a fraction of the overall cost.