Samsung TV Telemetry Analysis

Device

Model: Samsung TV (firmware SWU-OU_T-JZL6AKUC_01260_220615, build 2022-06-15)

TL;DR

The TV phones home every 5 seconds over plaintext HTTP with a connectivity beacon. It also broadcasts its MAC address and local API endpoints on the LAN every 2 seconds. Netflix push notifications arrive over unencrypted WebSocket on port 80. Firmware update checks leak exact model and firmware version in the URL. When “off,” the TV goes completely silent — no standby beacons.

Power-On Sequence (repeats every boot)

Always the same order:

The firmware check hits the same path every time:

/firmware/tv/448/SWU-OU_T-JZL6AKUC_01260_220615/OUITHeaders.dat

/firmware/tv/448/SWU-OU_T-JZL6AKUC_01260_220615/OUITHeaders.dat

Leaks: platform code (448), firmware ID, build date.

Continuous Background Telemetry

1. Samsung Cloud Connectivity Beacon — every 5 seconds

GET http://cdn.samsungcloudsolution.com/Public/network/files/check.xml
→ 200 OK, 53 bytes, text/xml
<?xml version="1.0" encoding="UTF-8"?>
<rsp>ok</rsp>

GET http://cdn.samsungcloudsolution.com/Public/network/files/check.xml
→ 200 OK, 53 bytes, text/xml
<?xml version="1.0" encoding="UTF-8"?>
<rsp>ok</rsp>

• Runs constantly while TV is on — 4,879 requests observed in one capture
• Plaintext HTTP to Akamai CDN IPs (23.221.236.x)
• Response is always the same 53-byte <rsp>ok</rsp>
• Purpose: connectivity liveness check. If response changes, TV likely triggers re-registration or config refresh
• No User-Agent, no cookies, no identifying headers — but the IP identifies the household

2. Samsung BSDP Discovery Beacon — every 3 seconds

SEARCH BSDP/0.1
DEVICE=0
SERVICE=1

SEARCH BSDP/0.1
DEVICE=0
SERVICE=1

• Sent to both 239.255.255.250:15600 (multicast) and 10.x.y.255:15600 (broadcast), alternating
• Samsung proprietary Broadcast Service Discovery Protocol
• LAN-only, does not leave the local network

3. SSDP/SmartThings Alive Beacon — every 2 seconds

{
  "type": "alive",
  "ttl": 8000,
  "remote": "1.0",
  "sid": "5C:49:7D:64:7D:D5",
  "data": {
    "v1": {"uri": "http://10.x.y.z:8001/ms/1.0/"},
    "v2": {"uri": "http://10.x.y.z:8001/api/v2/"}
  }
}

{
  "type": "alive",
  "ttl": 8000,
  "remote": "1.0",
  "sid": "5C:49:7D:64:7D:D5",
  "data": {
    "v1": {"uri": "http://10.x.y.z:8001/ms/1.0/"},
    "v2": {"uri": "http://10.x.y.z:8001/api/v2/"}
  }
}

• Sent to 224.0.0.7:8001 (multicast)
• Exposes: MAC address, local IP, two unauthenticated API endpoints
• v1 = Samsung Remote Control protocol (used by SmartThings app)
• v2 = Samsung REST API (can read/write TV state, launch apps, inject keystrokes)
• LAN-only but any device on the network can control the TV

4. Netflix Push WebSocket — every ~28 minutes

GET http://nrdp.push.prod.netflix.com:80/ws

GET http://nrdp.push.prod.netflix.com:80/ws

• Plaintext HTTP on port 80 — all WebSocket frames unencrypted
• Maintains persistent connection; reconnects on ~28-minute cycle
• On power-on, fires 4 rapid reconnects in ~300ms (retry storm)
• Also: TLS connections to nrdp.logs.netflix.com (logging), appboot.netflix.com (app init), secure.netflix.com (auth)

5. Samsung Analytics Upload — every 10 minutes

TLS → lcprd1.samsungcloudsolution.net:443 (34.160.212.185)

TLS → lcprd1.samsungcloudsolution.net:443 (34.160.212.185)

• Encrypted — cannot inspect payload without an intercept proxy
• Consistent 10-minute interval suggests batched telemetry upload
• Companion TLS to sas.samsungcloudsolution.com (Samsung Account Service) on power-on

6. Disney+ Config Polling — every ~10 minutes

TLS → config-cd-dmgz.bamgrid.com (config)
TLS → disney-curated-partner-feeds-prod.bamgrid.com (content feeds)

TLS → config-cd-dmgz.bamgrid.com (config)
TLS → disney-curated-partner-feeds-prod.bamgrid.com (content feeds)

• Always paired — config check + feed refresh together
• Even when Disney+ is not actively in use

7. Samsung Ad Tracking — sporadic

TLS → cdn-stv.adgrx.com (Samsung's ad platform, hosted on CloudFront)
TLS → tvx.adgrx.com
TLS → rtb.adgrx.com (real-time bidding)

TLS → cdn-stv.adgrx.com (Samsung's ad platform, hosted on CloudFront)
TLS → tvx.adgrx.com
TLS → rtb.adgrx.com (real-time bidding)

• AdGear is Samsung’s owned ad-tech subsidiary
• rtb.adgrx.com = real-time bidding endpoint — TV is participating in ad auctions
• Observed on Sep 5 and Sep 7

8. Samsung Profiling Endpoints — on power-on

All TLS, all to samsungelectronics.com:

Naming convention suggests different telemetry dimensions. All resolve to Akamai. All TLS — payload unknown.

Plaintext Exposure Summary

Traffic Volume (TV outbound, per hour)

Key finding: TV goes completely silent when off. No standby beacons, no periodic wake-ups. All telemetry is strictly “while powered on.”

DNS Query Counts (from latest capture)

Recommendations

1. Block cdn.samsungcloudsolution.com at the firewall — stops the5-second plaintext beacon. TV will still function; it just won’t report “ok” to Samsung’s CDN every5 seconds.

2. Block *.samsungqbe.com and *.samsungelectronics.com — stops profiling and QBE telemetry. May disable some SmartHub features.

3. Block adgrx.com — stops ad tracking and RTB participation. May break ad-supported Samsung TV Plus.

4. Netflix on port 80 — blocking port 80 outbound forces Netflix to use TLS. Or block nrdp.push.prod.netflix.com specifically and Netflix will fall back to TLS push.

5. VLAN isolation — the SSDP/BSDP beacons on ports 8001 and 15600 expose the TV’s MAC and API to the entire LAN segment. Put IoT devices on a separate VLAN.

6. The 5-second check.xml is the odd pattern — no legitimate reason for a TV to poll a CDN every 5 seconds. This is a presence/telemetry beacon masquerading as a connectivity check. The fixed response means Samsung can change it to trigger device behavior (forced update, remote config push, etc.).