TL;DR

We rooted a Samsung TV to find out how residential proxy code ends up in living rooms. Below, we discuss how Bright Data's SDK sits dormant inside licensed games like Pac-Man until a remote switch flips it on, what traffic we saw leaving an exit node in our lab, and why the way these apps are built makes any app store review process very difficult to enforce.

A brief history of residential proxies

Residential proxies - software that routes other people's web traffic through home internet connections - are nothing new, though they have seen a resurgence in the era of AI. Malicious threat actors, AI companies, and data aggregation firms share a common problem: their traffic needs to appear legitimate, or they risk getting blocked. Routing traffic through a "clean" IP address goes a long way toward evading traditional IP reputation checks.

Around the mid-2010s, we started to see an uptick in compromised home routers and free VPN apps. The uses ranged from threat actors masking their attack traffic all the way to regular people trying to watch Netflix catalogues from other countries. The latter sometimes unintentionally joined the peer-to-peer networks that enabled the former. See - Hola: A free VPN with a side of botnet (ZDNET).

Fast forward to the present day and we have a mature market of residential proxy services, spanning everything from operators that enforce consent and know-your-customer policies to backdoored smart picture frames (FBI) used by cybercriminals.

Smart TVs are the perfect place to hide

There has been a flurry of reporting about residential proxy networks and smart TVs. Spur reported that "Nearly Half of LG Smart TV Apps Are Laced with Proxies", and shortly after, Brian Krebs reported that LG had decided to ban residential proxies from their app store.

After all, an always-on, internet-connected device present in so many homes would be a great place to run a residential proxy.

It has been fairly well documented that the less reputable residential proxy networks obtain their access through backdoored devices like IPTV boxes, picture frames, and compromised routers. However, we wanted to better understand what the more reputable side of the space looked like. What was the path to getting an exit node inside our homes, and what did traffic from the "ethically sourced" networks actually look like?

At this point you could basically expect to see something sketchy happening with a bargain-bin $20 IPTV box, but what about a reputable TV manufacturer? We decided to start with Samsung.

Research in this space is tricky

You could run network traffic analysis on a TV, but this only tells a small part of the story. Nearly all traffic today is encrypted, so you'll basically just see that X talked to Y. Best case, you download a few apps and hope one reaches out to a known proxy network - not an approach that gets you very far, or that scales well.

To thoroughly answer questions like which apps contain residential proxies, what conditions they get activated under, and what the consent flows look like, you need to root a device.

Samsung goes to great lengths to prevent this, and understandably so. Smart TVs contain specialized hardware and encryption keys to support DRM. A rooted TV could allow an attacker to pirate content from apps like HBO and Netflix.

A side effect of this is that it inhibits legitimate security research. If an app is doing something malicious or otherwise undesirable, it becomes very difficult to investigate. We have to place full trust in Samsung's app store review process. Third-party review becomes effectively impossible.

To get root on our own test device, we used several techniques - among them chip-off extraction, which means desoldering the TV's flash chip to read the firmware directly. We'll leave you with one snippet we turned up along the way.

Bright Data

Bright Data is a company that specialises in data collection - think LinkedIn profile harvesting, or Amazon pricing and product review information. At the time of writing, they advertised 789 different types of ready-made datasets.

Bright Data also operates a substantial residential proxy network. Spur Intelligence estimates that in July 2026 they operated approximately 9.5 million exit nodes worldwide. They were the most prominent residential proxy operator in Norway at this time, with about 3,000 nodes on Telenor's residential fiber ASN alone.

Bright Data, formerly named Luminati Networks, was founded as a division of Hola VPN in 2014. Hola VPN is no stranger to controversy - see the link above.

In recent years, Bright Data has implemented consent policies - basically a pop-up telling users their device will be used as a residential proxy - as well as know-your-customer (KYC) checks for those wishing to route traffic through the residential proxy network. KYC is a practice borrowed from banking, where a provider verifies a customer's identity and stated purpose before granting access, on the theory that anonymous customers are the ones most likely to abuse the service. Today, Bright Data advertises that they are "Leading the way in ethical web data collection." [1]

Sorting through the app store

Bright Data's own developer documentation told us they supported Samsung's Tizen platform, and data from Spur told us they were among the most prominent residential proxy network operators, so that seemed like a natural starting point. Fairly quickly, we were able to identify quite a few suspect apps.

Spur and Include Security have publicly researched this space as well. Spur's research focused on breadth, identifying the scale across the app store, while Include Security primarily focused on Bright Data's iOS implementation.

We figured we could best contribute by digging deep into a small subset of apps, and by focusing on anything Tizen-specific.

Side tangent

The Samsung app store is an utter security nightmare. We did some quick string searches across the apps and found everything from hard-coded API keys, to developer certificates, to notes left behind by AI coding agents. Alas, we need to stay focused - a task for another day.

Play.Works

Play.Works is a game development house that focuses on the "lucrative Connected TV market". [2] They advertise that their portfolio spans over 400 games, and that they have installations in over 400 million homes.

They appear to license many well-known games and intellectual properties, such as Space Invaders, Tetris, Pac-Man, Doodle Jump, and SpongeBob, and port them to platforms like Samsung, Apple TV, LG, and Sony, as well as set-top boxes from various TV network operators like Sky, Comcast, and AT&T.

We identified that their apps contained the Bright Data SDK, and, to our surprise, one of their apps, Pac-Man, was recommended to us under Samsung's "Editor's Choice" section. Was an unsuspecting consumer just a couple of clicks away from joining a residential proxy network while sitting on the couch?

The answer is complex, almost by design.

A dormant switch

The simple answer is no - installing Pac-Man did not turn our TV into a residential proxy exit node. But it can, at the flip of a remotely controlled switch.

Play.Works ships their games with a copy of Bright Data's SDK embedded inside. By default, it lies dormant. When a game is launched, it reaches out to a configuration server and decides what to do.

Below is an extract from a configuration response; "enabled": true is the logic that, in this case, activated the SDK for a football-themed 2048 game. Pac-Man did not contain this flag at the time of writing.

When the switch was "flipped", the app did in fact present the consent screen, though it's easy to see how somebody - a child, maybe - might press accept just to get to the next screen and keep playing.

Once a user has agreed to enable the Bright Data SDK, a background service is activated. The SDK will continue to run even if the user navigates away from the app. The Tizen platform supports this via a service definition in config.xml , a file that defines app permissions similar to Android's manifest.

Below is an example of the relevant service definition from the Pac-Man game.

When we conducted our research, most of the Play.Works apps had the Bright Data SDK configured in a dormant state. Coincidentally, this was during the same period in which discussions around residential proxies were in the news. Without historical data, we're not able to see whether more apps were previously enabled and subsequently disabled.

However, the fact remains that a simple code change on a web server could activate more than 400 million (according to Play.Works) residential proxy nodes.

The app store review problem

The 20 lines of HTML below are the entire Pac-Man game that's shipped to the Samsung app store (minus some simple JavaScript and CSS). The app is an empty shell; a web browser loads the game logic on the fly from a Play.Works server.

You can imagine how this might present some challenges for both Samsung's and Bright Data's app review processes. The entire app can be swapped out at any time - including the SDK configuration data, as we showed earlier.

For what it's worth, this design makes sense for other reasons as well. Developers can fix bugs without having to upload a new app to the store and wait for users to update.

However, we saw this to be a repeating pattern across the app store, and a less-than-honest app developer could abuse this architecture to easily slip past Samsung's, Bright Data's, or anyone else's quality control processes.

If Samsung were to implement a similar policy to LG's and ban apps containing residential proxies, an app developer could honestly say that their app adheres to the policy, then swap out the code at a later point in time. For Samsung, or any app store maintainer for that matter, continually reviewing apps with dynamically loaded code is not a simple or straightforward task.

Traffic analysis

We conducted traffic analysis of a Bright Data exit node. The SDK opens a TCP socket to the destination and forwards the raw bytes over a WebSocket connection back to Bright Data. We were able to decrypt the WebSocket control traffic between our node and Bright Data, but further inspection of the forwarded traffic would break the TLS trust of the issuing client.

We were, however, still able to log the SNI from the TLS ClientHello message to get a rough idea of what was going on. With the caveat that we are only able to see a very small percentage of the traffic routed over Bright Data's network, and have limited insight into that traffic, most of it does in fact appear to be legitimate on the surface - though the definition of legitimate may be open to interpretation here.

Most of the traffic appears to be related to Bright Data's dataset services: a large number of requests to LinkedIn and various web stores. onlinebooks.library.upenn.edu suggests possible AI training data collection.

Initially, a few domains stood out, in particular edge-auth.microsoft.com and accounts.google.com . Our suspicion was that they could have been used in adversary-in-the-middle or other account takeover attacks, but further analysis based on the timing of the requests suggested these were more likely related to LinkedIn profile harvesting.

Below is a list of the top 50 SNIs, sorted by number of individual connections observed.

Conclusion

Nothing we found in the Play.Works apps was hidden in the way malware is hidden. The SDK ships dormant, a consent screen is presented when it wakes up, and Bright Data has consent and know-your-customer policies in place. And yet the distance between an "Editor's Choice" Pac-Man game and an exit node in your living room is one server-side configuration change and one button press from whoever happens to be holding the remote.

That is the uncomfortable part. The consent screen is real, but what is being consented to is less clear, and the person consenting may well be a child trying to get back to the game. Meanwhile, the app itself is twenty lines of HTML pointing at a web server. What was reviewed is not necessarily what is running.

This is the structural problem for app store maintainers, and it is worth being fair about how hard it is. Writing a policy is the easy part; enforcing it against code that is fetched at runtime is something else entirely. LG's ban is a meaningful signal, but in an ecosystem built on dynamically loaded shells, a ban is a promise about code the store maintainer may never see.

Samsung's own app recommendations surfaced an app carrying this SDK to us. Editor's Choice is not passive hosting - it is an endorsement. One manufacturer is banning residential proxies while another is promoting apps that ship the machinery for them. Add to that the complexities of researching this space (chip-off firmware extraction) and the result is an ecosystem where the only party able to verify what these apps do is the same party recommending them.

It is worth being explicit about what we did and did not look at. We deliberately aimed at the most visible end of this ecosystem: the largest TV manufacturer, one of the largest connected TV game publishers, and the largest residential proxy operator. These are the actors with reputations to lose, and compliance teams to answer to - and they can still change what an app does long after it has been reviewed. If the architecture allows that here, it allows it everywhere, and everywhere else there is far less scrutiny. A small developer with an obscure app, no brand to protect, and actual malicious intent has the same remote switch available, no consent screen obligation they intend to honor, and nobody watching closely enough to notice. The well-lit end of this space is the part we can describe; it is not the part we would worry about most.

We plan to keep pulling on this thread: widening the set of apps and platforms we examine. If you are working on something similar, we would like to hear from you.

[1]: https://brightdata.com/ (Accessed July 2026)
[2]: https://play.works/team (Accessed July 2026)