Markdown files

This commit is contained in:
Emily 2018-12-21 03:12:10 +01:00
parent b64471ae0c
commit dbc850e58b
2 changed files with 59 additions and 2 deletions

23
NOTES.md Normal file
View File

@ -0,0 +1,23 @@
# Important notes for myself
Keep code as forward as possible and don't mix with structure.
Write notes about implementation and usage for documentation sake.
Read though implementation multiple times for improvement potential when working on core elements. (This does not mean make it as complex and difficult to understand as possible)
Have fun and enjoy coding.
# TODO
[ ] Decide theme and style
[ ] Animation layout and framework
[ ] Scrape binary or html from filesystem to get custom native objects and functions
[ ] Structure menuing
[ ] Event loop management
[ ] Priority system
[ ] Dynamic/Selective events from html
[ ] Templates for menus
# Maybe
[ ] Rewrite templating system to allow language packs
(Reason being I design for english and can't run my own dynamic html engine on the TV as of yet)
# Along the way
- Find out if I should rewrite the codebase with typescript and if so; maybe compile to WASM
- Consider themability

View File

@ -1,3 +1,37 @@
# Philips_TV # 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)
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](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.