360 Hardware Details

[xb0xmod]

salut!

Un yankee viens de m'envoyer un tas d'info sur le hardware non dispo selon lui sur free60.org!!

il ne ma pas dis d'ou sa viens ,mais sa à l'air trés proche de la realité !

--------------------------------------------------------------------------------

NAND attached to southbridge

dump

1. sector: copyright notice, zeros, unencrypted numbers

2. sector: encrypted data

@2MB filesystem, unencrypted, but content encyypted, config not

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

dumps of physical memory

changed 1 byte in software, dumped again, 16 bytes changed again.

might be ~1 cache line

(0, 1, 2, ...)

log:

| |

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 6e bb c5 d1 62 9e 29

8f e9 3a 6b 7b 4d d0 44 24 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 03 58 f6 c0 f0 13 d5

02 4f 57 a1 d0 50 d3 46 6a 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 1b d6 a6 3b 3c 6e 68

4f da 75 7f a7 8a 02 e4 53 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 38 03 ff f0 61 99 e6

8c b0 3b 2f bb b6 70 06 53 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 0f 55 01 b1 61 9b 35

34 4d ce f4 e8 bb eb cc 4a 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 fc ce 87 2c 30 c0 1c

4f e7 65 da d4 e4 df f6 2b 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 e5 5d f3 38 d9 05 c0

8e 7a a9 b5 a2 fe 11 4c b3 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 84 83 5d 34 55 9b e4

06 26 03 1b f3 0b e9 0f b8 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

f0 35 64 03 de 02 5b 09 b5 7b 81 49 21 e9 d9 77 ba 4d 72 2b cd 0b e9

0c 2b aa ed 53 ea b0 63 49 15 d4 61 28 e0 e2 ea da e3 b8 34 2e cf bb

af 0e

compare hypervisor reading and pm dump: not done...

---------

after each reboot, it looks different

* virtual reading of hypervisor is different

* PM dump is different

---------

logical mapping:

7feaxxxx is ea00xxxx (some mapped pci region)

8xxxxxxx is ram

800xxxxx is hypervisor code

there are many other mappings

----------

physical address mapping:

c000xxxx: Initial "Kernel" (bootloader, not real kernel), probably

mapped L2-Cache?

c8xxxxxx: memory mapped NAND flash (read only, 1:1 mapping, no ECC

bytes)

c9xxxxxx:

d0xxxxxx: PCI config space. Device number etc. is encoded in address,

as usual

e0000000: Host-Bridge

ea000000: PCI-to-PCI bridge

ec800000: GPU

ea000000: different peripheral:

ea001000: bus control

ea001010: UART

ea00102x: GPIO

ea00103x: GPIO

ea00104x: GPIO

ea00105x: SMI

ea0012xx: SATA #1

ea0013xx: SATA #2

ea001400: NIC

ea001600: XMA decoder (audio)

ea001800: unknown (probably audio related)

ea002000: USB #1 (EHCI)

ea004000: USB #2

ea00c000: NAND interface, indirect access

PCI config region

------------------

SLOT 0, device 0 @(ea000000)

58001414 00100000 06040002 00010000 <-- 06 -> PCI-to-PCI-bridge

00000004 00000000 00020100 000000f0

0000fff0 0000fff0 00000000 00000000

00000000 000000d0 00000000 00000100

SLOT 0, device 1 @(e0000000)

58101414 00100002 06000011 00000000 <- host bridge

e0000000 ffffffff ffffffff ffffffff

ffffffff ffffffff ffffffff 00000000

ffffffff 00000000 ffffffff ffffffff

SLOT 0, device 2 @(ec800000)

58111414 00100002 03800011 00000000 <-- 03 -> "other" display controller

e4000000 ffffffff ffffffff ffffffff

ffffffff ffffffff ffffffff 00000000

ffffffff 00000050 ffffffff ffffffff

SLOT 1, device 0 @(ea001800) some audio related stuff. :/

58011414 02000000 00000000 00000000 <-- 00 (unspecified . really

unknown device.

00000000 00000000 00000000 00000000 <-- has 1 MM space (size: 0x400),

but returns only 0,0,0,0,1,0,0,0,0,..,0,1,0,0,..

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000100

SLOT 1, device 1 @(ea001200,ea001220) SATA (cdrom)

58021414 02300000 01060000 00000000 <-- mass storage: Serial ATA,

vendor specific interface

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000

00000000 00000058 00000000 00000100

SLOT 1, device 2 @(ea001300,ea001320) SATA (disk)

58031414 02300000 01060000 00000000 <-- mas storage (2nd?)

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000

00000000 00000058 00000000 00000100

SLOT 1, device 4 @(ea002000)

58041414 02800000 0c03100f 00800000 <-- serial bus controller

00000000 00000000 00000000 00000000

00000000 00000000 00000000 58041414

00000000 00000000 00000000 50000100

SLOT 1, device 5 @(ea004000)

58061414 02800000 0c03100f 00800000 <-- serial bus controller

00000000 00000000 00000000 00000000

00000000 00000000 00000000 58061414

00000000 00000000 00000000 50000100

SLOT 1, device 7 @(ea001400) NIC

580a1414 02100000 02000001 00000000 <- ethernet

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000

00000000 00000040 00000000 00000100

SLOT 1, device 8 @(ea00c000,c8000000) NAND

580b1414 02000000 05010000 00000000 <-- memory controller (flash)

00000000 c8000000 00000000 00000000 <-- has one more memory region,

probably direct access. see below. final config: ea001600, 00000000

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000100

SLOT 1, device 9 @(ea001600) XMA stuff

580c1414 02800000 04010001 00000000 <- audio

00000000 00000000 00000000 00000000

00000000 00000000 00000000 75011039

00000000 00000000 00000000 0b340100

SLOT 1, device 10 @(ea001000) Bus Control (0x0C), Serial Port (0x10),

GPIO (0x20..0x40), SMI (0x50..0x80)

580d1414 02000002 00000000 00000000

ea001000 00000000 00000000 00000000 <-- really has no interesting

stuff here. final config: same.

00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000100

device 10: serial port, gpio!

also accessible from user space

----------------

disassembling old kernel - it accesses a serial port

SERIAL PORT!!: debug info written to on debug box, 115k

boot monitor: send special character '@' -> talk to boot monitor

plaintext interface

you can read/write memory, execute code

bootloader runs before hypervisor setup

boot monitor works on physical memory

write to pci config space possible, read memory, write memory

c000xxxx: THE interesting stuff is HERE!!!!

can't be accessed - hangs

c8xxxxxx NAND - bootloader reads from there, copies to RAM

hack: use network to dump in boot monitor, just didn't work :-

( something might not be configured yet

*read

*write

*init ram

everything before uses no ram

in bootloader: 1010101010 patterns - bus/memory training?

-----

13 pin header next to southbridge: left two pins are TX/RX of serial

port

X X X X X X X

X X X X X X

serial EEPROM next to processor?

couldn't find any activity

(board can do i2c)

the i2c bus on the board does not seem like used for booting (like 970)

looks more like simple stuff

very simple i2c communication, a few bytes

-----------

possible attack

HV code can read itself, and can read unencrypted data in RAM, like

plaintext hashing

change single bits -> destroy 16 bytes in hypervisor

at system call address

SC

illegal instruction

do this over and over again

might be a jump instruction

32 MB of NOPs then out code

destroy

hope that it's jump

there can be no protection if network writes

because security system is in the CPU

this needs to work ONCE to dump the HV

------

TCPA spec says: northbridge has function to disable DMA for memory

regions (but reading is possible) -- perhaps this is done on the 360

HV and user encryption probably different

HV static

user: bit in pagetable?

------

claim is:

routine that hashes, tests key code sequences

no... could change a lot

------

as soon as we have control

fuse to get a simpler key?

recovery cd can update bootloader

function xenckeyssavesystemupdate: load already encrypted block into

memory, reencrypt it, write it to flash -> HV can reencrypt

bootloader with per-xbox key

------------------------------------------------------------------------------------------

[gold]

Merci, par contre je n'ai pas trop de temps pour exploiter tout ça mais je trouverais bien une faille ne stressez pas

Pour revenir au sérieux, je vous félicite de plancher sur cette 360

[Atmoz]

Y a pas un pro qui pourrait faire une traduction des passages en anglais, mais surtout, de tout ce qui est dit ci dessus. Bref, si un pro passait par la, et avait quelques minutes pour décortiquer tout ça et expliquer un peu à ceux qui n'y connaissent rien, ce que tout ça veut dire, ce serait bien gentil

Et puis qui sait, peut etre que ceux qui n'y connaissaient pas grand chose avant, pourront peut être apporter leur aide après traduction

[legolas820]

Avec 13 de moyenne en anglais je comprends pas tout .

Qui pourrait traduire SVP ???

[eremation]

normal que tu ne comprenne pas tous meme avec 13 de moyenne en anglais car le texte est tres acces informatique/programmation/electronique.

meme traduit en francais tu ne comprendra pas tous.

[loling]

C'es très intéressant,jespère que je pourrait modifier tous ca

[nounours59330]

C'es très intéressant,jespère que je pourrait modifier tous ca

mdr on voit que tu ne a rien comrpsi a ce qui a etait dit !

[SpOkEr]

De toute façon ce mec comprend rien ... et comprendra rien ..

Il était temps qu'il soit BAN ! (malheureusement qu'une semaine ..)

[XxSpiritFroO]

C'es très intéressant,jespère que je pourrait modifier tous ca

mdr on voit que tu ne a rien comrpsi a ce qui a etait dit !

Slt ,

On reconnait surtout les exités du freeposting . Il a déjà pris 2 jours par moi et 1 semaine par legueux , j'éspère que ca va lui passer l'envie de pourrir les topic .

Sinon xb0xmod pas mal les infos mais le "yankee" il vient de quel forum ?

Merci

++

[xb0xmod]

C'es très intéressant,jespère que je pourrait modifier tous ca

mdr on voit que tu ne a rien comrpsi a ce qui a etait dit !

Slt ,

On reconnait surtout les exités du freeposting . Il a déjà pris 2 jours par moi et 1 semaine par legueux , j'éspère que ca va lui passer l'envie de pourrir les topic .

Sinon xb0xmod pas mal les infos mais le "yankee" il vient de quel forum ?

Merci

++

salut

je tiens ces info d'un mec de xboxhackers!

C'est relativement compliqué et ne presente

pas un grand intérré pour le moment, mais qui c'est un jour peu étre

@+