Difference between revisions of "GTV FileSystem"

From Exploitee.rs
Jump to navigationJump to search
(Created page with "The Google TV File System is similar to most other Android Operating Systems. == Updates == Updates to the Google TV, unlike most the incremental updates that most Android phon...")
 
 
(25 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The Google TV File System is similar to most other Android Operating Systems.
The Google TV File System is similar to most other Android Operating Systems.


== Still Needs ==
* Finishing  merging update information from the [[ Logitech_Revue_Technical]] page including proper truncation and hex editting steps.  also mentions odex.
* Description of how the Update Signing process works and how it works (And why we can't just copy an edited zip to a usb key and root the box).  This is a common noob question.
* Description of the seperation between the boot loader steps, recovery kernel, and the actual "device" file system/kernel.  This can be key for explaining how the UART1 console was used and when it was used.  There is often discussion on "I was looking for output during X boot stage" that this data could provide a definition for.


== File System Layout ==
The File System is created by the mounting of 13 partitions into a *nix-based file system.
Below is a list of the paritions, their contents, and their mount points:
{| border="1"
| Identifier?
| Partition Name
| Description
| Mount Point
|-
|0x00000000-0x00200000
| "mbr"
| Mostly blank, repeats "01c0000 b00b dead 000f a901 0000 0000 0000 0000"
|
|-
| 0x00200000-0x00a00000
| "cefdk"
|  The boot loader.  Presumably compiled under Intel's "Consumer Electronics Firmware Development Kit" ([http://software.intel.com/en-us/articles/intel-tools-for-intel-atom-processors/ Got $2,000?])<br/>It's data&mdash;wouldn't say it is encrypted, but no strings visible.  It may contain a console.
|
|-
| 0x00a00000-0x00c00000
| "redboot"
| All FF's <br /> [http://www.redhat.com/services/custom/embedded/redboot/ "Red Hat Embedded Debug and Bootstrap"]
|
|-
| 0x00c00000-0x00e00000
| "cefdk-config"
| Holds Box SN, repeats (like MBR)
|
|-
| 0x01000000-0x01800000
| "splash"
| Splash image, [ http://img413.imageshack.us/img413/3144/splashc.png visible here] .  It reports itself as a BMP even though it is a PNG
|
|-
| 0x01800000-0x01900000
| "fts"
| Flash Transaction Key/Value Storage. (Contents seem to be just seems to be just: "F*TS..e.L.......bootloader.command=boot-recovery.bootloader.recovery=recovery.--wipe_data.")
|
|-
| 0x01900000-0x02d00000
| "recovery"
| Full image, including kernel and small ramdisk (in squashfs format), boots to recovery menu
|
|-
| 0x02d00000-0x03200000
| "kernel"
| The kernel image
|
|-
| 0x03200000-0x07200000
| "boot"
| Root partition, goes in hand with the kernel image, also in squashfs format
|
|-
| 0x07200000-0x1f200000
| "system"
| Holds most of the crucial system files (including the Kernel). It's YAFFS
| /system
|-
| 0x1f200000-0x3fa00000
| "data"
| Where user data is stored. YAFFS
|
|-
| 0x3fa00000-0x3ff00000
| "keystore"
| Don't delete this . Has Keys for communication w/ Google & Logitech YAFFS
|
|-
| 0x3ff00000-0x40000000
| "bbt"
| Bad Block Table
|
|}
Sources:
* MTD Parition listing came from [http://googletv.pastebin.com/233dZqZx Revue Boot Output]. ([http://my.safaribooksonline.com/book/operating-systems-and-server-administration/embedded-linux/0136130550/mtd-subsystem/ch10lev1sec3 What's an MTD partition?])<br/>
* Partition mount points came from /init.rc & init.<board>.rc
== Kernel ==
Information on the Kernel can be found at [[Logitech Revue Kernel]].  Important to note that the Revue Kernel has been modified from what is available in the Google Open Sourced GTV Source.
== Updates ==
== Updates ==
Updates to the Google TV, unlike most the incremental updates that most Android phones receive, come as a complete file system meant to replace the previous.  It is assumed that since Google TV devices are meant to be connected to high speed internet connections, downloading a full File System is more palatable than on a limited-bandwidth mobile device.
Updates to the Google TV, unlike the incremental updates that most Android phones receive, come as a complete file system meant to replace the previous.  It is assumed that since Google TV devices are meant to be connected to high speed internet connections, downloading a full File System is more palatable than on a limited-bandwidth mobile device.
 
The Google TV software uses the [[com.google.android.systemupdater]] activity to periodically query Google's servers looking for available updates based on the devices serial number.  Under normal circumstances, during initial setup of a device (i.e. configuring from a wiped or factory default state), the [[com.google.android.systemupdater]] activity will prevent completion of first time setup until any available updates have been downloaded and applied. This can be bypassed by removing the files /system/app/SystemUpdater.{apk,odex} from the file system.  If a previously configured device finds an available update at boot, it will display a prompt asking the user if they wish to install or defer the update.  If the system is not in use at this time, the update will be applied without user interaction.  Based on network traffic it appears that the Logitech Revue is configured to check for updates in the early AM hours.  The currently installed build number can be checked through '''Applications > Settings > About'''.  (See [[GoogleTV - Version Numbers]] for more information).  Updates are distributed as signed zip files including [[boot.img]], [[kernel.img]], [[ota.prop]], updated content, and meta-information (signing data, install scripts, etc).
 
Until a new recovery image with is prepared for Google TV devices, it is unlikely that anyone will be able to prepare homebrew updates since it is computationally infeasible to produce signatures matching Google's private key.  This same logic applies when considering modification of a properly signed update.
 
List of all updates for:
*[[LogitechRevueUpdates|Logitech Revue]]


Updates are retrieved without user intervention from the Google Servers.   You can use the device version number to check your current file system implementation (See [GoogleTV - Version Numbers] for more information)Updates are distributed as signed zip files including a recovery, system, and userdata imageBelow is a list of the currently known of update packages.
The Updates each include:
* boot.img: A file system including the root file system for the device.<
* The "system" folder: This is the guts of the Google TV and it's applicationsThese files are copied into the system folder on update.
* META-INF directory: Includes the manifest and other certificates shipped with the device for authentication.


*Logitech Update 1
== File System Obfusication ==
*Logitech Update 2
*Sony Update 1
*Sony Update 2
*Sony Update 3
(Maybe they should be numbered by the GTV version number dislplayed post update...)


== How to access the File System contained within an image ==
== How to access the File System contained within an image ==
Line 21: Line 112:
Some data on the process is available here:
Some data on the process is available here:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
== GTV Recovery Mode vs GTV(System) Mode ==
== GTV Boot Loader ==
The Boot Loader is included on the File System, currently in the X directory.  The Boot Loader is based off of the Y Loader (More information can be found at Z).
For the Sony BlueRay player, the Boot Loader is ABC.
== Files of interest within the File System ==
[[Category:Contribute]]

Latest revision as of 20:52, 28 June 2012

The Google TV File System is similar to most other Android Operating Systems.

Still Needs

  • Finishing merging update information from the Logitech_Revue_Technical page including proper truncation and hex editting steps. also mentions odex.
  • Description of how the Update Signing process works and how it works (And why we can't just copy an edited zip to a usb key and root the box). This is a common noob question.
  • Description of the seperation between the boot loader steps, recovery kernel, and the actual "device" file system/kernel. This can be key for explaining how the UART1 console was used and when it was used. There is often discussion on "I was looking for output during X boot stage" that this data could provide a definition for.

File System Layout

The File System is created by the mounting of 13 partitions into a *nix-based file system.

Below is a list of the paritions, their contents, and their mount points:

Identifier? Partition Name Description Mount Point
0x00000000-0x00200000 "mbr" Mostly blank, repeats "01c0000 b00b dead 000f a901 0000 0000 0000 0000"
0x00200000-0x00a00000 "cefdk" The boot loader. Presumably compiled under Intel's "Consumer Electronics Firmware Development Kit" (Got $2,000?)
It's data—wouldn't say it is encrypted, but no strings visible. It may contain a console.
0x00a00000-0x00c00000 "redboot" All FF's
"Red Hat Embedded Debug and Bootstrap"
0x00c00000-0x00e00000 "cefdk-config" Holds Box SN, repeats (like MBR)
0x01000000-0x01800000 "splash" Splash image, [ http://img413.imageshack.us/img413/3144/splashc.png visible here] . It reports itself as a BMP even though it is a PNG
0x01800000-0x01900000 "fts" Flash Transaction Key/Value Storage. (Contents seem to be just seems to be just: "F*TS..e.L.......bootloader.command=boot-recovery.bootloader.recovery=recovery.--wipe_data.")
0x01900000-0x02d00000 "recovery" Full image, including kernel and small ramdisk (in squashfs format), boots to recovery menu
0x02d00000-0x03200000 "kernel" The kernel image
0x03200000-0x07200000 "boot" Root partition, goes in hand with the kernel image, also in squashfs format
0x07200000-0x1f200000 "system" Holds most of the crucial system files (including the Kernel). It's YAFFS /system
0x1f200000-0x3fa00000 "data" Where user data is stored. YAFFS
0x3fa00000-0x3ff00000 "keystore" Don't delete this . Has Keys for communication w/ Google & Logitech YAFFS
0x3ff00000-0x40000000 "bbt" Bad Block Table

Sources:

Kernel

Information on the Kernel can be found at Logitech Revue Kernel. Important to note that the Revue Kernel has been modified from what is available in the Google Open Sourced GTV Source.

Updates

Updates to the Google TV, unlike the incremental updates that most Android phones receive, come as a complete file system meant to replace the previous. It is assumed that since Google TV devices are meant to be connected to high speed internet connections, downloading a full File System is more palatable than on a limited-bandwidth mobile device.

The Google TV software uses the com.google.android.systemupdater activity to periodically query Google's servers looking for available updates based on the devices serial number. Under normal circumstances, during initial setup of a device (i.e. configuring from a wiped or factory default state), the com.google.android.systemupdater activity will prevent completion of first time setup until any available updates have been downloaded and applied. This can be bypassed by removing the files /system/app/SystemUpdater.{apk,odex} from the file system. If a previously configured device finds an available update at boot, it will display a prompt asking the user if they wish to install or defer the update. If the system is not in use at this time, the update will be applied without user interaction. Based on network traffic it appears that the Logitech Revue is configured to check for updates in the early AM hours. The currently installed build number can be checked through Applications > Settings > About. (See GoogleTV - Version Numbers for more information). Updates are distributed as signed zip files including boot.img, kernel.img, ota.prop, updated content, and meta-information (signing data, install scripts, etc).

Until a new recovery image with is prepared for Google TV devices, it is unlikely that anyone will be able to prepare homebrew updates since it is computationally infeasible to produce signatures matching Google's private key. This same logic applies when considering modification of a properly signed update.

List of all updates for:

The Updates each include:

  • boot.img: A file system including the root file system for the device.<
  • The "system" folder: This is the guts of the Google TV and it's applications. These files are copied into the system folder on update.
  • META-INF directory: Includes the manifest and other certificates shipped with the device for authentication.

File System Obfusication

How to access the File System contained within an image

The Zip File is a simple matter to extract, however the images within them tack some massaging in order to explore. While they are a typical SquashFS File System, they have some padding bytes that prevented a simple "Unsquashing."

  • It would be great if we could create a way to use dd to truncate the image instead of using a hex editor. You should be able ot somehow grep for the start and then dd the proper bits into a new file that could be explored correctly.*

Some data on the process is available here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

GTV Recovery Mode vs GTV(System) Mode

GTV Boot Loader

The Boot Loader is included on the File System, currently in the X directory. The Boot Loader is based off of the Y Loader (More information can be found at Z). For the Sony BlueRay player, the Boot Loader is ABC.

Files of interest within the File System