javoriuski
GitHubHackerOneX

The Ghost Remote

@javoriuski | November, 2025.

It all started with a bit of casual curiosity.

I was in my university's dorm room, sitting with my laptop and running Burp Suite in the background to take a look at my phone's traffic, a common habit for anyone curious about security. I opened the Netflix app, not to watch, but to test. I tapped the "cast" icon, curious about what happens under the hood when your phone tries to connect with a TV.

Since I’m on a massive university network, I didn't just see my own devices. To my surprise, Burp's logs lit up. A long list of local IP addresses appeared. I was seeing every smart TV nearby that was on the network.

I picked my own TV and looked at the request my phone was trying to send:

POST /dial/Netflix HTTP/1.1
Host: 133.16.79.133:8060
Content-Type: text/plain; charset=utf-8

intent=sync

It was a simple, unencrypted HTTP POST request to port 8060. This was the lightbulb moment.

If my phone can send this single command to launch Netflix, what other commands can I send? I sent the request to Repeater, and started researching.

From "Launch" to "Control"

It's interesting that, after you connect your phone to a TV, all it allows you to do is simple tasks, right? Play a video, turn the volume up, turn the volume down, change channels, etc.

Wrong. If you have the TV's IP and PORT, you can do way more than that. It doesn't block a variety of other, way more interesting commands.

A bit of quick searching for API endpoints, I found the Roku External Control Protocol (ECP). I had stumbled onto a complete guide of different things I could do!

The experimentation began. I tested some endpoints:

  • POST /keypress/Home
    • Result: The TV instantly jumped to its home screen.
  • POST /keypress/VolumeUp
    • Result: The volume started climbing.
  • GET /query/device-info
    • Result: I had the TV's model, serial number, and some more information.
  • POST /launch/837?contentId=dQw4w9WgXcQ
    • Result: The TV immediately launched YouTube and started playing a very specific video.

I had full, unauthenticated remote control. I tried another IP from the list and I had the same level of control, but of course, all testing was strictly limited to my own device.

Is This a Bug? Or Just a Bad Feature?

Here's the most interesting part: this isn't technically a "bug".

For a regular user at home, everything is working as intended. They use their phone, go on Netflix or YouTube, and their phone magically finds their TV and connects. It's simple, seamless, and convenient.

The problem is that in the quest for that simplicity, this leaves a door wide open. It’s designed to accept a command to launch Netflix from an app, but it doesn't prohibit some "extra" access. I tried some more advanced requests and it failed due to limite access. However, it happily accepts commands to turn the TV on/off, crank the volume, or launch any other app.

The real issue is context. This feature was designed for a trusted home network. It was not designed for a massive, zero-trust university network where thousands of devices share the same space.

Who am I?

What makes this even cooler is: I can do everything without the victim ever needing to "accept" my connection to their TV.

There is no "Allow this device to connect?" pop-up. There is no pairing.

I can control their TV without any trace of who I am. To the person watching, it would just seem like their TV is haunted! Channels changing, apps opening, and the volume going crazy, all at the hands of a "ghost" on the network.

This fun discovery is a perfect example of a common problem in the "Internet of Things" (IoT). Devices are designed for convenience on a "trusted" network, forgetting that in 2025, no network should ever be fully trusted.

Javox (@javoriuski)