xboxscene.org forums

Pages: [1] 2

Author Topic: Lots of Technical Xbox 360 Hardware Details  (Read 1704 times)

Xbox-Scene

  • Archived User
  • Hero Member
  • *
  • Posts: 4299
Lots of Technical Xbox 360 Hardware Details
« on: December 06, 2005, 03:16:00 PM »

Lots of Technical Xbox 360 Hardware Details -- Posted by XanTium on December 6 17:09 EST
An anonymous source sent tons of details of the Xbox 360 hardware and security to the guys over at xboxhacker.net.
It's pretty technical, including NAND dump info, physical memory dump details, logical mapping, physical address mapping, PCI config region, hypervisor details, kernel details, details of syscalls used as communication between kernel and hypervisor ... and much more.

Check it out on xboxhacker.net or this XBH forum thread.

Logged

OcnewB

  • Archived User
  • Full Member
  • *
  • Posts: 209
Lots of Technical Xbox 360 Hardware Details
« Reply #1 on: December 06, 2005, 04:00:00 PM »

Cjack couldnt dump the rom/eeprom? And this guy could (and whatnot more). Cjack also said the eeprom didnt do anything, this guy also claims it pretty much doesnt do anything. (Correct me if im wrong pls).
I couldnt make anything from the rest.

1 more thing, the guy from ms claimed that what would work for one xbox wouldnt work for another. Its the same what this guy says:

"bootloader with per-xbox key"


@ this rate the 360 will be hacked sooner than i thought it would be..

If this information IS actually true and not some great MS hoax to get things even more confusing.

This post has been edited by OcnewB: Dec 7 2005, 12:09 AM
Logged

slappydooda

  • Archived User
  • Newbie
  • *
  • Posts: 40
Lots of Technical Xbox 360 Hardware Details
« Reply #2 on: December 06, 2005, 04:15:00 PM »

I had fun feeling smart while I read it, but (and this is directed towards anyone who's a little more technical) is this credible/possible? If so, what can we do with this? He kept mentioning some beta dvd he was useing... Was that available to many people...? How did this guy get one?
Logged

frOOt lOOps

  • Archived User
  • Jr. Member
  • *
  • Posts: 56
Lots of Technical Xbox 360 Hardware Details
« Reply #3 on: December 06, 2005, 04:23:00 PM »

i don't understand this much but i noticed a few interesting things.

1. he says that he could only dump the virtual RAM and that this ram is NOT encrypted. i think he says that he cannot dump the real ram but possibly a virtual memory exploit?

2. hypervisor can only do physical memory

3. bootloader runs before hypervisor setup.

so possibly a attack that utililzes the unencrypted virtual RAM memory and can find errors in bootlader code and get some homebrew code running before hypervisor kicks in to place. somehow disable hypervisor?

i am not a pro in this so if my idea's are dumb tell me. i will post the article for easy reading.

Okay here is the article right off of xboxhacker.net


"Updated: LOTS of 360 HW Detail/Info  
Written by SiliconIce    
Tuesday, 06 December 2005  
Updated: I have added a forum thread here for this news.

An anonymous, and I think reliable, source has put this in my email box for people to chew on. Someone seems to know/have discovered quite a bit about the hardware.

Take this with a grain of salt! I don't know where it came from, so there is no way to determine the accuracy (except to continue pulling the box apart!)

bunnie's paper is very close to reality

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: fuck 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 smile.gif. 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

 
Last Updated ( Tuesday, 06 December 2005 )  
   
More Pics (Flash, EEPROM desoldered)  
Written by SiliconIce    
Sunday, 04 December 2005  
cjack's page related to the two news items I posted earlier, a lot more disassembly pics:

http://www.darkmoon....360_photos.htm"

lots of info lets get somethin going!
 
 
 


 

Logged

c0d3_z3r0

  • Archived User
  • Full Member
  • *
  • Posts: 170
Lots of Technical Xbox 360 Hardware Details
« Reply #4 on: December 06, 2005, 04:37:00 PM »

QUOTE
@ this rate the 360 will be hacked sooner than i thought it would be..

That what I thought.


From what I've seen, it seems like the kernel holds the dash, and if we can dissasemble the kernel, we might be able to crack this thing.

Or....
It could be somone sending wrong info to mislead us.
Logged

RocketMBA

  • Archived User
  • Jr. Member
  • *
  • Posts: 55
Lots of Technical Xbox 360 Hardware Details
« Reply #5 on: December 06, 2005, 05:12:00 PM »

Man, that serial port setup sounds extremely interesting. I want in.
Logged

Math1

  • Archived User
  • Jr. Member
  • *
  • Posts: 60
Lots of Technical Xbox 360 Hardware Details
« Reply #6 on: December 06, 2005, 05:57:00 PM »

From the way he talks about beta kits and such, teh anonymous source is obviously a developer. He better hope he stays anonymous, though, else MS will have his balls hanging from Bill's keychain.
Logged

crosseye

  • Archived User
  • Full Member
  • *
  • Posts: 222
Lots of Technical Xbox 360 Hardware Details
« Reply #7 on: December 06, 2005, 05:59:00 PM »

If the information is not true, it won't take long before someone points it out. I would believe what this is saying because even MS would know that people would test to see if they could do the same and if they couldn't, the source would lose all credibility. I say lean towards being true. If it's not true, I wouldn't think it's MS trying to mislead anyone cause like I said, they KNOW we would try the same thing and the source would be flogged.
Logged

paper

  • Archived User
  • Jr. Member
  • *
  • Posts: 61
Lots of Technical Xbox 360 Hardware Details
« Reply #8 on: December 06, 2005, 06:01:00 PM »

As with the representative of MS claiming that if someone does eventually get somewhere with thier xbox  , it not working for another xbox, would the mystery behind some xboxs having no eeprom and others having eeprom have anything to do with it?
Logged

Deathman

  • Archived User
  • Newbie
  • *
  • Posts: 15
Lots of Technical Xbox 360 Hardware Details
« Reply #9 on: December 06, 2005, 06:00:00 PM »

ok im no tekky at all, but from what i could make out from that email the HV is capable of reencrypting the bootloader with a per box key .. so if the bootloader can be hacked in some way then the HV will automatically reencrypt it when its uploaded to the xbox.. so surely the fact its a per box key doesnt matter? forgive me if im wrong but thats what i got from the email..  biggrin.gif
Logged

SharkUW

  • Archived User
  • Jr. Member
  • *
  • Posts: 65
Lots of Technical Xbox 360 Hardware Details
« Reply #10 on: December 06, 2005, 06:34:00 PM »

only things i found to be interesting was the possibility that it could support a 2nd sata and a serial port.
Logged

Penna

  • Archived User
  • Newbie
  • *
  • Posts: 1
Lots of Technical Xbox 360 Hardware Details
« Reply #11 on: December 06, 2005, 06:36:00 PM »

I fail to see how he could get some of these information just by dumping some memory regions. If this is indeed true, this guy got access to undisclosed information.

But what keeps my hopes down is that this information was sent anonymously by e-mail. I just hope I'm wrong and someone confirms this is valid. It'd be a great step towards modding the Xbox 360.
Logged

TheSpecialist

  • Archived User
  • Full Member
  • *
  • Posts: 215
Lots of Technical Xbox 360 Hardware Details
« Reply #12 on: December 06, 2005, 07:20:00 PM »

QUOTE(OcnewB @ Dec 7 2005, 12:00 AM) View Post

 Cjack also said the eeprom didnt do anything, this guy also claims it pretty much doesnt do anything. (Correct me if im wrong pls).


Ok, you're wrong wink.gif Hehe. He says "serial EEPROM next to processor? Couldn't find any activity (board can do i2c)". This has been confirmed before, there's no activity on that bus.
Logged

frOOt lOOps

  • Archived User
  • Jr. Member
  • *
  • Posts: 56
Lots of Technical Xbox 360 Hardware Details
« Reply #13 on: December 06, 2005, 09:10:00 PM »

QUOTE(TheSpecialist @ Dec 7 2005, 03:27 AM) View Post

Ok, you're wrong wink.gif Hehe. He says "serial EEPROM next to processor? Couldn't find any activity (board can do i2c)". This has been confirmed before, there's no activity on that bus.


so are you saying that the eeprom does nothing because of when cJack desolrdered it and it changed nothing which would explain why there is no activity. but if there is no activty here and cJack also said that it pretty much does nothing because of the experiments he tried then why would it be there. why is it on some 360's and not on other's. (it has been random not just core or premium have eeprom some have them some don't). confusing though why some have an eeprom and some dont and it has nothing to do with core or premium.
Logged

jer_stud56

  • Archived User
  • Newbie
  • *
  • Posts: 29
Lots of Technical Xbox 360 Hardware Details
« Reply #14 on: December 06, 2005, 09:48:00 PM »

This is either a well thought of MS thing or someone that is deep inside the Xbox program that WANTS the scene to become aware of this info. If that's the case - then my idea of the modding of the xbox 360 in 6-8 weeks is trueeeeee. Woo.
Logged
Pages: [1] 2