imported>TEIR1plus2 |
imported>TEIR1plus2 |
| Line 29: |
Line 29: |
| ==CF== | | ==CF== |
| Loads CG into memory by reading the CG data in the NAND header and then reads the rest of the CG data from the CG blocks specified in CF header. It then decrypts the CG in memory using the key generated from decrypting CF. To verify it, it computes a RotSumSha1 and checks it against the known hash. If it matches, it uses LZX delta decompress to apply the patch to the base kernel in memory. Once its done, it jumps back to CD and once CD has finished up, it jumps to the reset vector in the [[Hypervisor]]. | | Loads CG into memory by reading the CG data in the NAND header and then reads the rest of the CG data from the CG blocks specified in CF header. It then decrypts the CG in memory using the key generated from decrypting CF. To verify it, it computes a RotSumSha1 and checks it against the known hash. If it matches, it uses LZX delta decompress to apply the patch to the base kernel in memory. Once its done, it jumps back to CD and once CD has finished up, it jumps to the reset vector in the [[Hypervisor]]. |
|
| |
| {{Cleanup}}
| |
| hypervisor
| |
|
| |
| no booting details known
| |
| changes between beta hardware and final:
| |
| alpha hardware = macintosh
| |
| beta = ? looks like retail, but no encryption
| |
| second beta =! retail
| |
|
| |
| tried to dump RAM
| |
| could only dump virtual memory
| |
| 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
| |
|
| |
| read memory using debug interface: everything is in plaintext, you
| |
| can read kernel + app (dashboard etc.), i.e. virtual memory is not
| |
| encrypted
| |
|
| |
| kernel interesting to disassemble
| |
| communication with hypervisor using syscalls
| |
|
| |
| hypervisor does interrupts/exceptions
| |
|
| |
| syscalls:
| |
| ***********************************
| |
| final:
| |
|
| |
| SC 00: GetVersionCode (e.g. r3=072F8002)
| |
|
| |
| SC 01: KeStartupProcessors
| |
|
| |
| SC 02: unknown KiQuiesce
| |
|
| |
| SC 03: KeFlushEntireTb
| |
|
| |
| SC 04: called in FlushMultipleTb
| |
|
| |
| SC 05: ??
| |
|
| |
| SC 06: KeGetSpecialPurposeRegister (r3=0x3F5)
| |
|
| |
| SC 07: KeSetSpecialPurposeRegister
| |
|
| |
| SC 08: KeGetSocRegister(r3=???)/KeGetPWMRegister(r3=60000)/
| |
| KeGetPRVRegister(r3=61000)
| |
|
| |
|
| |
| SC 09: KeSetSocRegister
| |
|
| |
| SC 0A: KeStartupProcessors
| |
|
| |
| SC 0B: called in ReserveKernelPtes
| |
|
| |
| SC 0C: called from MmAllocatePhysicalMemoryEx
| |
|
| |
| SC 0D: setAD16
| |
|
| |
| SC 0E: KeEnablePPUPerformanceMonitor
| |
|
| |
| SC 0F: called from MmGetPhysicalAddress
| |
|
| |
| SC 10: called from MmDbgReleaseAddress
| |
|
| |
|
| |
|
| |
| 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:Xbox360 System Software]] | | [[Category:Xbox360 System Software]] |
This page details the boot process used in the Xbox 360. The process is slightly different between Devkit/Retail and certain boxes which have a secondary CB loader (trinity/some jaspers)
Retail
1BL (Inside CPU)
Loads and decrypts CB(_A) into ram, it computes a RotSumSha1 of CB(_A) and uses it to verify its RSA signature. If the signature is valid, 1BL jumps to CB(_A).
CB
SLIMS ONLY: CB_A loads and decrypts CB_B into ram, it computes a RotSumSha1 of CB_B and checks it against the known hash. If it matches CB_A jumps to CB_B.
CB(_B) starts up a virtual machine, which does:
- initializes the PCI Bridge
- disables the GPU PCIE JTAG test port
- initializes the serial port
- talks to the SMC to clear the "handshake" bit
- initializes memory
- generates RROD if memory init fails
CB(_B) loads and decrypts CD into ram, it computes a RotSumSha1 of CD and checks it against the known hash. If it matches CB(_B) jumps to CD.
Methods to dump the CB bootloaders and examples of them reversed can be found here: CB Code
CD
Loads and decrypts CE into ram, computes a RotSumSha1 of CE. If it matches the known hash, it decompresses the LZX compressed base kernel.
It then checks for patch slots. If it finds one, it will load and decrypt the corresponding CF bootloader for that patch. It then computes a RotSumSha1 of CF and uses it to verify the CF loaders signature. If the signature is valid, CD stays in memory but jumps to CF.
There can be up to 2 CF/CG pairs for patching the kernel.
CF
Loads CG into memory by reading the CG data in the NAND header and then reads the rest of the CG data from the CG blocks specified in CF header. It then decrypts the CG in memory using the key generated from decrypting CF. To verify it, it computes a RotSumSha1 and checks it against the known hash. If it matches, it uses LZX delta decompress to apply the patch to the base kernel in memory. Once its done, it jumps back to CD and once CD has finished up, it jumps to the reset vector in the Hypervisor.