khanfarris

probing my own smart TV
2026-08-10  ·  Samsung TU700D (Tizen), Kali Linux  ·  runbook PDF

After the light bulbs went down easily, I wanted a target with an actual attack surface. My Samsung TU700D running Tizen has a dozen network services running at any given moment — a remote-control API, UPnP, DLNA, AirPlay, a Netflix endpoint, a web server. That's a lot of doors. So I went looking for one that was unlocked.

Spoiler: I didn't get in. But the interesting part of this one isn't a breach — it's learning to read a scan honestly, and understanding why "no exploit found" is not the same as "safe." Everything here was done on my own TV, on my own network.

Step 1 — Finding the TV

sudo nmap -sn 10.0.0.0/24

Same opening move as always: a ping sweep that lists every host and its MAC vendor. I picked the one tagged Samsung Electronics — it was at 10.0.0.234. The vendor tag is how I ID'd it, not by guessing which IP looked like a TV.

Step 2 — Enumerating every open door

sudo nmap -sV -sC -p- 10.0.0.234

Full TCP scan, version detection, default scripts. This is the core of the whole exercise: build a complete inventory of what's exposed before touching anything. The TV was noticeably chattier than the bulb. Key open ports:

Step 3 — Reading the results skeptically

This is the step I would have skipped a year ago, and it's the most important one. nmap tells you a port's state, and the states mean different things:

Lesson: the service names nmap prints for filtered or unknown ports — things like teradataordbms — are just its guess based on the port number, not real detection. I only trust the service name when the state is open and -sV actually got a reply. On this TV, the SSL certificate was the real proof: commonName=SmartViewSDK, country KR. Certs and Server headers don't lie the way a port-number guess does.

Step 4 — The control API and its auth model

pip install samsungtvws --break-system-packages

python3 -c "from samsungtvws import SamsungTVWS; \
SamsungTVWS(host='10.0.0.234', port=8002, token_file='tok.txt', name='KaliRemote').send_key('KEY_VOLUP')"

I want to be precise about what this is. Using send_key over the official protocol is using a feature, not exploiting a bug. The only security question that matters is: does it require authorization?

On 2016-and-later Tizen, it does. The moment I sent that key, the TV popped an on-screen "Allow this device?" prompt and wanted to issue a token. That prompt is good security — the TV refused to be controlled by a stranger without a human physically approving it.

Step 5 — Checking auth without lighting up the screen

curl -s http://10.0.0.234:8001/api/v2/ | python3 -m json.tool

The consent prompt only fires on the control channel. This device-info endpoint is read-only, unauthenticated, and completely silent — no prompt, no token. It handed me the model and firmware (useful for CVE lookup) and one very telling field: TokenAuthSupport: true. That confirms the control channel enforces auth. It isn't weak; it's on.

How I knew to hit http://IP:8001/api/v2/

The URL breaks down into four parts, and each one came from somewhere specific:

Finding the path came from three things, in order:

  1. Deduction — apps control TVs through an API, so an API endpoint has to exist somewhere.
  2. Convention — APIs live under /api/ and get versioned as /v1/, /v2/.
  3. Brute force — if the first two fail, gobuster or ffuf spray a wordlist of common paths at it.
Lesson: curl fetches one path I chose — it doesn't discover anything on its own. Knowing it was v2 and not v1 came from checking docs and source, and from testing which one returned 200 vs 404. Discovery is on me, not the tool.

Step 6 — The CVE hunt, and the trap in it

My exact target: model UN75TU700D / 21_KANTSU2E (2021 Tizen), remote API 2.0.25, developerMode=0, TokenAuthSupport=on. The inputs for any vulnerability search are vendor + product + version, and I now had all three. 

searchsploit samsung tizen      # check it, but expect No Results for a TV
The key lesson of this whole writeup: searchsploit came back empty. Its one hit — "SmartViewer BackupToAvi" — is unrelated Windows CCTV software, a false positive. And an empty searchsploit does not mean "no vulnerabilities." searchsploit only indexes Exploit-DB, which is published exploit code, and that barely covers consumer IoT. For a TV, the real information lives in web searches, NVD, researcher blogs, and papers.

Where I actually look, in order

  1. Web search — "samsung tizen smart tv CVE / vulnerability / exploit." Most productive; surfaces researcher blogs and news.
  2. NVD (nvd.nist.gov) plus OpenCVE / CVE Details — the formal records with version ranges and severity.
  3. Researcher blogs (Bishop Fox and others), the Full Disclosure seclist, arXiv.
  4. searchsploit / Metasploit last — check them, but expect empty for IoT. They shine for server software, not TVs.

Judging each CVE against my actual config

Finding a CVE isn't the end — I have to check whether its preconditions match my setup. Three examples that all came back "doesn't apply":

Lesson: a real, published CVE can exist for my exact OS and still not apply, because its preconditions aren't met. When firmware showed "Unknown" over the network, I got the exact version straight from the TV — Settings > Support > About This TV — and matched it against the CVE lists by hand.

Verdict & fix

Verdict: a patched, developer-mode-off, token-auth-on 2021 TV is not trivially owned by public CVEs. The one current RCE is gated behind developer mode, which is off — and that off switch is my protection. "The device properly requires consent" is a legitimate finding, even though it isn't a breach.

Remediation: keep developer mode off, keep firmware updated, and put the TV on a separate IoT/guest VLAN so its pile of services — UPnP, AirPlay, NRDP — is isolated from the PCs and phones on the main network.

The repeat checklist

  1. nmap -sn to find the Samsung IP by vendor.
  2. nmap -sV -sC -p- <ip> to enumerate every service.
  3. curl http://<ip>:8001/api/v2/ to read the model and TokenAuthSupport silently.
  4. Research CVEs — web search and NVD first, searchsploit last (expect empty for IoT), using model + firmware.
  5. Match each CVE's preconditions against my actual config before concluding anything.

Same workflow fits any device. Swap the IP, research its services, and read the results honestly.

The full runbook

Every command and note above, in a single reference sheet:

🔒 protected document

This runbook is password protected. Enter the password to continue:

Wow, good job. I presume you used this method to find the password:

  1. Right-clicked the page and hit View Page Source (or pressed Ctrl + U).
  2. Skimmed the JavaScript near the bottom of the page.
  3. Found the password sitting right there in plaintext — itsnotpasswordprotected — because on a static site there's nowhere to hide it.

Or maybe you:

  1. Realized this is a static site whose source repo is public on GitHub — and just read the file list there.
  2. Or brute-forced the site root with gobuster/ffuf and a wordlist, watching for a 200 on a .pdf.
  3. Or simplest of all — noticed this very button spells out the filename, so you just tacked it onto the site root (khanfarris.com/Samsung_TV_Pentest_Runbook.pdf) and opened it directly. No password required.

…which is the whole joke. Client-side "passwords" on a static site are theater. Anyway — here's your document: