Boot Process: Difference between revisions

From Xenon Wiki
Jump to navigation Jump to search
imported>Tuxuser
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Cleanup}}
This article describes the boot sequence of the Xenon platform.
hypervisor


no booting details known
= Power On Process =
changes between beta hardware and final:
<br/>
alpha hardware = macintosh
<center>[[File:Bootprocess.png|1500px]]</center>
beta = ? looks like retail, but no encryption
== 1BL ==
second beta =! retail
The first bootloader. This is stored in the CPU ROM and is loaded first when the console is powered on.


tried to dump RAM
== CB (aka 2BL) ==
could only dump virtual memory
The second bootloader. This is decrypted/loaded by 1BL and is stored within the NAND.
ram is at 8000_0000
southbridge: pci config space, mapped to VM, accessible by user apps
memory at bottom looks random/encrypted, might be hypervisor 256 KB


8040_0000 xbox kernel starts, MZ header
RSA signed using asymmetric crypto.


read memory using debug interface: everything is in plaintext, you
== CD ==
can read kernel + app (dashboard etc.), i.e. virtual memory is not
Loaded/decrypted by CB. This loads, decrypts and decompresses CE, which contains the base kernel + base HV (Hypervisor).
encrypted


kernel interesting to disassemble
== CF ==
communication with hypervisor using syscalls
Loaded/decrypted by CD. This loads, decrypts and decompresses CG, which contains the patches for kernel and HV.  It then applies the patches and starts up the patched HV and then the patched kernel.  It then boots to the dashboard.


hypervisor does interrupts/exceptions
RSA signed using asymmetric crypto.


syscalls:
= OLD ALPHA BOOT PROCESS =
***********************************
This article describes the boot sequence of the PowerPC G5 starting a Xenon kernel and OS.
final:
== Overview ==


SC 00: GetVersionCode (e.g. r3=072F8002)
The PowerPC G5 has a ROM containing the openfirmware (OF) bios, as well as a NVRAM containing variables used by the openfirmware to find bootable partitions or bootloaders like yaBoot or BootX(MacOSX). Its the task of openfirmware (OF) to find and start the os.


SC 01: KeStartupProcessors
The basics are:
* After CPU reset vector and cpu initialization the boot ROM stored in NVRAM provides power on self test (POST - diagnostics), and initializes enough of the system to load Open Firmware. When enough initialization has occurred to execute Open Firmware, the boot chime is played and Open Firmware is loaded.
* OpenFirmware (Init) will then probe the system's I/O buses to determine the device configuration and build a device tree.. the system will then examine the values of its enviroment variables. If the auto-boot? variable is flagged as true, the system will then read the value... and attempt to boot from that device. If additional information is required the boot-file variable is read. If the auto-boot? variable is flagged as false, the system will halt the boot process and drop to the Open Firmware user interface.
* Default Boot Device on Apple systems is "hd:,\\:tbxi". ("tbxi", tells the system to look for files of type tbxi. )
* the tbxi (bootfile) is started and from here on we follow the "Xenon" bootpath instead of the MacOSX.


SC 02: unknown KiQuiesce
=== Xenon boot from OF ===
In case of the Xenon Alpha, we found that a special Partition called [[XeBoot]] is at the beginning of the harddrive. This contains either or what we asume 2 files, a bootx file (like MacOSX, containing a configuration script) and a xboxroma.bin file, wich is a (stripped ?) ELF file like the MacOSx kernel. This "rom" file will start looking for the Xenon OS kernel on various devices and start it.
[[citation needed]]
Known location the xboxroma.bin is looking:
* \Device\Cdrom0\*
* \Device\Harddisk0\Partition1\xboxroma.bin
* \Device\Harddisk0\Partition1\xboxrom_update.bin
* \Device\Harddisk0\Partition3\ROM\0000\xboxroma_1mb.bin
(NT/WINworld notation) [[citation needed]](is this realy the rom, or kernel that does check if its running the latest kernel?)


SC 03: KeFlushEntireTb
When the latest kernel is found and started it will locate its Dashboard or XShell files and optionaly if found, start the XBDM.dll (named XBDM.XEX)


SC 04: called in FlushMultipleTb
== Extra information ==
* OF will automatically convert "hd" into the appropriate device path, as hd is simply an alias. The notation "\\" tells the system to start searching for "blessed" folders (directories) starting on the first HFS or HFS+ partition found on the system.


SC 05: ??
* All versions of MacOS have a folder known as System Folder that is "blessed", and contains a MacOS Boot ROM file which is of type tbxi. The Boot ROM file is simply a stripped ELF executable image wrapped with a forth boot script.


SC 06: KeGetSpecialPurposeRegister (r3=0x3F5)
* A "blessed" folder is simply one with a special attribute (or flag) set on it. The system will search all HFS partitions for a bblessed folder and a file of type tbxi within it, if none are located, the boot will fail. The system will always select the first one found, unless the boot-device is modified to a specific partition id.


SC 07: KeSetSpecialPurposeRegister
"tbxi", tells the system to look for files of type tbxi.


SC 08: KeGetSocRegister(r3=???)/KeGetPWMRegister(r3=60000)/
== Openfirmware ==
KeGetPRVRegister(r3=61000)
To get into openfirmware, press Command () + Option () + O + F [[citation needed]]


=== commands in openfirmware ===
The following commands work in the openfirmware used in the Apple G5 version known to boot Xbox software
[[citation needed]] (Please check commands on real Mac and add missing helpful commands)
{| class="wikitable"
|-
! Command !! Explanation
|-
| boot [option] || boot the device stored in NVRAM variable boot or boot the given option [[citation needed]]
|-
| ls || list the current device list (handy to find if a device is found by OF and its partitions are listed) [[citation needed]]
|-
| devalias || list all current known aliases for devices [[citation needed]]
|-
| printenv || prints all currently environment variables and their default values (if available)
|-
| setenv || used to change or set an environment variable
|-
| eject cd || ejects the optical drive (if available)
|-
| reset-all || reboots the system
|-
| reset-nvram || sets up a factory defaults reset of the NVRAM on reboot
|-
| set-defaults || sets a flag that restores all defaults contained within the BootROM to the NVRAM on reboot
|}


SC 09: KeSetSocRegister
=== Reverting OF into MacOSX bootable state ===
try booting macos from OF by typing:
<pre>mac-boot</pre>[[citation needed]]
If this fails, try checking if the bootdevice is actualy set by typing:
<pre>nvram boot-device</pre>[[citation needed]]


SC 0A: KeStartupProcessors


SC 0B: called in ReserveKernelPtes
Asuming the Harddisk containing MacOSX is reinserted and NVram or Openfirmware is not able to boot macosx, try:
<pre>setenv auto-boot true</pre>[[citation needed]]


SC 0C: called from MmAllocatePhysicalMemoryEx


SC 0D: setAD16


SC 0E: KeEnablePPUPerformanceMonitor
== Resourses ==
* [https://openfirmware.info/Welcome_to_OpenBIOS] Opensource website used by the openfirmware on the apple G5
* [https://books.google.nl/books?id=K8vUkpOXhN4C&pg=PA344&lpg=PA344&dq=macosx+bootdevice+OF&source=bl&ots=OMkhRYYw-C&sig=cATnoVTg7ShRia8tvxZr4y_cy6o&hl=nl&sa=X&ved=2ahUKEwi24oel7rLcAhUJM-wKHe9EBKQQ6AEwDnoECAQQAQ#v=onepage&q=macosx%20bootdevice%20OF&f=false] Mac OS X Internals: A Systems Approach (paperback)
* [http://mac.linux.be/content/guide-open-firmware-apple-bios-0] Guide to openfirmware on the Apple


SC 0F: called from MmGetPhysicalAddress


SC 10: called from MmDbgReleaseAddress
[[Category:Xbox 360 System Software]]
 
 
 
SC 11: XexpLoadFile calls it, seems to get privkey
 
r4 = phys addr (of header?) offset: +8
 
r5 = region
 
r6 = ?? offset: +4
 
r7 = ?? size?
 
 
SC 12: called from MmAllocateImageMemory
 
SC 13: called from MmAllocateImageMemory
 
 
 
SC 14: called in XexpLoadFile
 
SC 15: called in XexpLoadFile
 
 
SC 16: called in XexpCompleteImageLoad
 
SC 17: called in XexpCompleteImageLoad
 
 
SC 18: called in XexpLoadFile, XexpCompleteImageLoad
 
SC 19: unload?
 
SC 1A: unload?
 
SC 1B: unload?
 
SC 1c: called on XexpTitleTerminateNotification
 
 
SC 1d: KeCreateUserMode
 
SC 1e: KeDeleteUserMode
 
SC 1f: Flush TLB
 
SC 20: set power
 
SC 21: shadow boot
 
SC 22: f*** fuses
 
SC 23: FSB interrupt related
 
SC 24: KeLockL2
 
 
 
SC 25:
 
SC 26
 
SC 27
 
SC 28
 
SC 29
 
SC 2A
 
SC 2B
 
SC 2C: SataCdRomHvVerifyLBA
 
SC 2D
 
SC 2E: XeKeysInitialize (r3, r4 = address)
 
SC 2F: XeKeysGetKeyProperties
 
SC 30: XeKeysGetStatus
 
SC 31: XeKeysGenerateRandomKey
 
SC 32: XeKeysGetFactoryChallenge
 
SC 33: XeKeysSetFactoryResponse
 
SC 34: XeKeysSaveBootLoader
 
SC 35: XeKeysSaveKeyVault
 
SC 36: XeKeysSetKey
 
SC 37: XeKeysGetKey
 
SC 38: XeKeysGetDigest
 
SC 39: XeKeysQwNeRsaPrvCrypt
 
SC 3D: XeKeysDesCbc. r6: address, r5: context
 
 
 
SC 3F: XeKeysSaveSystemUpdate
 
SC 40: XeKeysExecute
 
**********************************
 
 
SC 22 =
 
tested on 2 kernels
 
first: SC "access fuses"
 
second: "burn fuses"
 
(rumour has it that this is used to make retail boxes out of debug
boxes)
 
 
memory management 0F/10: perhaps page table access code in
hypervisor, all high level code in kernel
 
 
you can't map memory as you like
 
network adapter in the southbridge
 
debug code dumps registers with names
 
it is possible to dump physical memory using network adapter DMA
accesses
 
not perfect dump
 
 
reading physical memory = encrypted
 
data segments are not encrypted, but nearly all code segments
 
 
older recovery cd (early 2005), worked on first beta developer kits,
without security enabled:
 
cd included kernel which included stuff that is encrypted in retail
version
 
includes hypervisor code!
it is old, but...
 
getspr: SC 6
 
setspr: SC 7
-> possible to see implementation of basic syscall handling
 
 
function in hypervisor to chain-run a new kernel from the old kernel
 
 
hypervisor: sign with private key etc.
 
hypervisor can only do physical memory
 
hashing: load into register base address, length, destination of hash
buffer, call syscode, hypervisor will hash
-> attack: hash 1 byte, *itself*, -> hangs
 
 
hypervisor lies at 0 in VM and physical mem
 
[[Category:Xbox System Software]]

Latest revision as of 05:22, 29 December 2018

This article describes the boot sequence of the Xenon platform.

Power On Process


Bootprocess.png

1BL

The first bootloader. This is stored in the CPU ROM and is loaded first when the console is powered on.

CB (aka 2BL)

The second bootloader. This is decrypted/loaded by 1BL and is stored within the NAND.

RSA signed using asymmetric crypto.

CD

Loaded/decrypted by CB. This loads, decrypts and decompresses CE, which contains the base kernel + base HV (Hypervisor).

CF

Loaded/decrypted by CD. This loads, decrypts and decompresses CG, which contains the patches for kernel and HV. It then applies the patches and starts up the patched HV and then the patched kernel. It then boots to the dashboard.

RSA signed using asymmetric crypto.

OLD ALPHA BOOT PROCESS

This article describes the boot sequence of the PowerPC G5 starting a Xenon kernel and OS.

Overview

The PowerPC G5 has a ROM containing the openfirmware (OF) bios, as well as a NVRAM containing variables used by the openfirmware to find bootable partitions or bootloaders like yaBoot or BootX(MacOSX). Its the task of openfirmware (OF) to find and start the os.

The basics are:

  • After CPU reset vector and cpu initialization the boot ROM stored in NVRAM provides power on self test (POST - diagnostics), and initializes enough of the system to load Open Firmware. When enough initialization has occurred to execute Open Firmware, the boot chime is played and Open Firmware is loaded.
  • OpenFirmware (Init) will then probe the system's I/O buses to determine the device configuration and build a device tree.. the system will then examine the values of its enviroment variables. If the auto-boot? variable is flagged as true, the system will then read the value... and attempt to boot from that device. If additional information is required the boot-file variable is read. If the auto-boot? variable is flagged as false, the system will halt the boot process and drop to the Open Firmware user interface.
  • Default Boot Device on Apple systems is "hd:,\\:tbxi". ("tbxi", tells the system to look for files of type tbxi. )
  • the tbxi (bootfile) is started and from here on we follow the "Xenon" bootpath instead of the MacOSX.

Xenon boot from OF

In case of the Xenon Alpha, we found that a special Partition called XeBoot is at the beginning of the harddrive. This contains either or what we asume 2 files, a bootx file (like MacOSX, containing a configuration script) and a xboxroma.bin file, wich is a (stripped ?) ELF file like the MacOSx kernel. This "rom" file will start looking for the Xenon OS kernel on various devices and start it. citation needed Known location the xboxroma.bin is looking:

  • \Device\Cdrom0\*
  • \Device\Harddisk0\Partition1\xboxroma.bin
  • \Device\Harddisk0\Partition1\xboxrom_update.bin
  • \Device\Harddisk0\Partition3\ROM\0000\xboxroma_1mb.bin

(NT/WINworld notation) citation needed(is this realy the rom, or kernel that does check if its running the latest kernel?)

When the latest kernel is found and started it will locate its Dashboard or XShell files and optionaly if found, start the XBDM.dll (named XBDM.XEX)

Extra information

  • OF will automatically convert "hd" into the appropriate device path, as hd is simply an alias. The notation "\\" tells the system to start searching for "blessed" folders (directories) starting on the first HFS or HFS+ partition found on the system.
  • All versions of MacOS have a folder known as System Folder that is "blessed", and contains a MacOS Boot ROM file which is of type tbxi. The Boot ROM file is simply a stripped ELF executable image wrapped with a forth boot script.
  • A "blessed" folder is simply one with a special attribute (or flag) set on it. The system will search all HFS partitions for a bblessed folder and a file of type tbxi within it, if none are located, the boot will fail. The system will always select the first one found, unless the boot-device is modified to a specific partition id.


"tbxi", tells the system to look for files of type tbxi.

Openfirmware

To get into openfirmware, press Command (⌘) + Option (⌥) + O + F citation needed

commands in openfirmware

The following commands work in the openfirmware used in the Apple G5 version known to boot Xbox software

citation needed (Please check commands on real Mac and add missing helpful commands)
Command Explanation
boot [option] boot the device stored in NVRAM variable boot or boot the given option citation needed
ls list the current device list (handy to find if a device is found by OF and its partitions are listed) citation needed
devalias list all current known aliases for devices citation needed
printenv prints all currently environment variables and their default values (if available)
setenv used to change or set an environment variable
eject cd ejects the optical drive (if available)
reset-all reboots the system
reset-nvram sets up a factory defaults reset of the NVRAM on reboot
set-defaults sets a flag that restores all defaults contained within the BootROM to the NVRAM on reboot

Reverting OF into MacOSX bootable state

try booting macos from OF by typing:

mac-boot

citation needed

If this fails, try checking if the bootdevice is actualy set by typing:

nvram boot-device

citation needed


Asuming the Harddisk containing MacOSX is reinserted and NVram or Openfirmware is not able to boot macosx, try:

setenv auto-boot true

citation needed


Resourses

  • [1] Opensource website used by the openfirmware on the apple G5
  • [2] Mac OS X Internals: A Systems Approach (paperback)
  • [3] Guide to openfirmware on the Apple