firmware decryption + rooting attempts
#################################
WARNING: don't look at the following information nor try to use any of it if you have no clue about linux or android as it is most likely that you are going to break your expensive gadget. For every one else: don't blame philips if you brick your device -> think before actually trying. If you post about vulnerabilities and stuff better cover your ass - who knows what the legal department of philips thinks about your cool stuff.
#################################
So as you decided to ignore my warning, here we go:
I already spent plenty of time researching the internals of the device in order to get root privileges. Unluckily without the final breakthrough - but at least I found out some very interesting details.
You might ask what those extended privileges should be good for? Well in my eyes android - a project available as open source with uncountable possibilities for developers and users - should not be closed down by profit oriented manufacturers. As those are often forcing the users into their own "crappy" software without given them any chance to escape. I like to develop at system base, use the underlying linux tools and most important check what the manufacturer does (behind my back) in my own living room. Hell I bought this expensive device and have no idea and can't nearly control what is sent to Philips nor Google.
1. I wrote a tool to decrypt the official firmware. It was created via reverse-engineering the "upgrade.bin" arm-file (thanks for the trace, snoerenberg).
Some interesting details about the used cryptography:
- openssl library functions
- used algorithm: aes-256 in CBC mode
- the encryption key is generated via "EVP_BytesToKey" using only the first 127 byte of the keyfile + an eight byte salt found near the beginning of every input file
Source-Code: attachment or pastebin_com / z3nA2r3J
maybe mirroring this paste and the source would be a good idea (Google for the HASH if link is down)
The decrypted firmware archive contains the following files:
boot.img.zip: kernel + initrd + ramdisk (unknown file format)
bootloader.zip: bootloader (unknown file format)
tzk_normal.img.zip: ? maybe recovery (unknown file format)
user_setting.zip: content of /user_setting
system.img.zip: content of /system (ext4-img)
firmware.img.zip: content of /firmware (ext4-img)
BackEndBin.zip, EdidBin.zip, fpgaUhdBin.zip, RougeBin.zip: different binary files - supposedly firmware for these components
As you see I was not able to extract the most interesting part (kernel + ramdisk) - Hopefully some android experts could help!
The current and some older firmware files could be downloaded at philips_samipupu_com (thanks for hosting)
2. General information:
- Kernel version: Linux version 3.4.70+ (build.ci@indbrnblx041) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Nov 14 01:52:21 IST 2014
- Kernel cmd-line: androidboot.hardware=AND1E quiet lpj=11935744 root=/dev/ram0 androidboot.console=ttyS0 console=ttyS0,115200 init=/init vmalloc=448M quiet macaddr=00:00:00:00:00:00 emmc_ts.dev_id=1 emmc_ts.size=16777216 emmc_ts.erasesize=524288 emmc_ts.writesize=512
- lsmod:
usb8797 359014 3 - Live 0x00000000
usb97mlan 290809 1 usb8797, Live 0x00000000 (P)
mbtusbchar 52685 0 - Live 0x00000000
usbfwdnld 8530 0 - Live 0x00000000
fusion 96777 0 - Live 0x00000000 (O)
tpvinput 7132 2 - Live 0x00000000 (O)
trcext 333860 0 - Live 0x00000000 (O)
gal3d 161434 16 - Live 0x00000000
amp_core 72528 2 - Live 0x00000000 (O)
tzlogger 1199 0 - Live 0x00000000 (O)
tzd 32013 30 amp_core,tzlogger, Live 0x00000000 (O)
3. The trcext module seems to be very interesting as a short look with a disassembler revealed that it might be able to read and manipulate process memory of any process. Maybe someone good at kernel-drivers could take a look?
4. There are two world-readable directories containing very interesting information:
- /data/debugdump: stack-traces, process-lists, short memory excerpts based on crashes of the native binaries (could be very helpful for exploiting)
- /data/anr: davlik crash-dumps of android applications
5. There are 3 SGUID and 1 SUID binaries (visible):
-rwxr-s--- root inet 5500 netcfg
-rwxr-sr-x root net_raw 26072 ping
-rwsr-s--- root shell 9464 run-as
6. The recovery menu which could be used to install a "new" firmware if the device does not boot properly could be reached via the following steps:
- unplug the power
- press and hold the joypad on the backside of the TV downwards
- replug
- release the joypad after 10 sec
7. There is a Customer-Service-Menu at “123654” which contains read only information about the current firmware and so one. However there is also the real service menu (062?96i) which could be used for much more things. But you need to be really careful with this, i already managed to break booting without changing something important.
8. The settings-app calls the "su" command inside of CSMActivity. If this is no obsolete debug code (i was not able to trigger this part yet) than there could be a "su" inside /sbin. The Manifest also shows this strange "org.droidtv.tv.tv_power_system_access" permission. Therefore i tried to write my own app with the same permission and call "su" which did however not work out (even if I use the same namespace org.droidtv.?)
9. Every time you pop in an usb stick android creates an backup folder on it. The filenames are "hidden" via base64 and there are some junk bytes at the beginning of the files which you need to crop in order to read them. However the content is quite boring mostly some sqlite3 databases with configuration parameters.
10. By default the usb sticks you plug in is read-only for user apps. However there is in option in the settings to re-format it. This will result in an XFS formatted, read-write mounted stick where you could even outsource your apps.
11. There is a soap (http) service running on port 1925 which is used by the philips remote app and allows different things for example starting one of the installed apps. More details could be found if you decompile the XTV-App.
Hope some of you guys could do something fancy with those information.
@snoerenberg(xda): did you manage to send commands over your cable yet - If you do rooting should be quite easy from this point (maybe /system/bin/run-as).
Cheers,
5003b4d49cbf7916123271b7b1918f123cca0c09bf1428f4398257751ac6570c
ps: some of the information were dumped on an older firmware and some with the current one
