Xbox360 Forums > General Technical Hacking Discussion
Lots of Technical Xbox 360 Hardware Details
Xbox-Scene:
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.
OcnewB:
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
slappydooda:
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?
frOOt lOOps:
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 . 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!
c0d3_z3r0:
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.
Navigation
[0] Message Index
[#] Next page
Go to full version