37 lines
3.6 KiB
Markdown
37 lines
3.6 KiB
Markdown
# 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 didn’t take longer then a day before I couldn’t 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 doesn’t 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 don’t 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 doesn’t 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](https://www.youtube.com/watch?v=4-StKSGXhHw) 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.
|
||
|
||
## Info
|
||
Some javascript objects and functions are part of native code that extends of the opera browser.
|
||
When debugging and developing you should always use the python (3) module called `main.py`.
|
||
|
||
Note that when deploing to TV the python module is not required.
|
||
It only serves as a micro service to emulate some TV specific actions.
|
||
Only the root folder should be required.
|
||
|
||
## Details
|
||
Root: `www`
|
||
Entrypoint: `index.html`
|
||
|
||
## TV Installation
|
||
#### 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. |