Project to rewrite the interface and interaction for the Philips Smart TV to a more structured and extendable way (Not a mix of 40+ different people that all have their own code style and knowledge)
Go to file
2020-04-29 16:58:59 +02:00
files Yes... I forgot to commit during writeups etc. 2020-04-29 16:58:59 +02:00
research Yes... I forgot to commit during writeups etc. 2020-04-29 16:58:59 +02:00
.gitignore Initial commit 2018-12-20 23:26:24 +00:00
AUTHORS.md Yes... I forgot to commit during writeups etc. 2020-04-29 16:58:59 +02:00
LICENSE Initial commit 2018-12-20 23:26:24 +00:00
NOTES.md I am still new to markdown 2018-12-21 03:14:48 +01:00
README.md Yes... I forgot to commit during writeups etc. 2020-04-29 16:58:59 +02:00

Philips TV

Project to rewrite the interface and interaction for the Philips Smart TV to a more structured and extendable way (Not a mix of 40+ different people that all have their own code style and knowledge)

Backstory

I bought my first Smart TV at black Friday 2018. I got shocked at how sluggish the interface and controls where. It didnt take longer then a day before I couldnt take it much longer and checked if I could do something about it. I scanned for ports on my network and found some websockets being open and to my surprise they allow you to send commands to the TV. It turns out that the reason everything is so slow and sluggish is due to every menu and interface just being a web window showing DOM elements that when being interacted with run some javascript that runs some custom native functions to change stuff.

In theory that is not too bad although very surprising... After digging around for a bit, my boyfriend found out that there was a security flag that have been turned off in the browser build that changes how cross-origin policy works. Essentially you can load local files using file:/// path in the browser. He then made a file browser that allowed us to go through the filesystem and look at different files. Although this was neat, we needed a way to get the files onto our PC for analysis as opening a binary in text doesnt really help us much.

As I am a python fanatic myself I wrote a module that talks with the websocket directly and requests all files in order (byte for byte) and then reassemble it on the end. This turned out to work fine with the exception of some symlink loops in the filesystem that I luckily spotted due to the method I choose to map out the filesystem before downloading.

After looking a bit closer at the source there was no wonder why it was so sluggish and running so poorly. Due to miscommunication and rushed release date (I am guessing), multiple people have their own ideas and they dont work well together. A combination of hacky code and bad choice of flow the system has a lot of wait time. There is even some places where there is hardcoded wait time instead of using events. I should also mention duplicated code and cases where they just return to the main menu if something doesnt go as planned in their if branches. (That is one way of handling an avoidable “crash”...)

After this I started looking into making my own filebrowser (as I like design), along with finding other exploits. I started looking into the USB filebrowser and 2 ideas struck me. One being just make a symlink to the root directory of the filesystem and the other being xss since the filename was shown on screen within a HTML page.

Turns out both worked as planned and I ended up making a video showing of the USB xss exploit to load my filebrowser.

I will try to write new discoveries and ideas with results in the research folder.

Project

TV Installation

Research and better understanding of the system is first required before making anything. All research along the way has been documented in research and files.
Bellow does not apply (yet).

Current methods of installing includes

  • USB Injection
  • Websocket injection

Methods will be further explained at a later point in time.
Other methods might be found at a later time and will be added to the list.