Xbox 360 Hombrew


Recommended Posts

It turns out the hyper visor is not perfect

from www.xbox-scene.com

Security Advisory: Xbox 360 Hypervisor Privilege Escalation Vulnerability

Release Date:: February 28, 2007

Author: Anonymous Hacker

Timeline:

* Oct 31, 2006 - release of 4532 kernel, which is the first version

containing the bug

* Nov 16, 2006 - proof of concept completed; unsigned code running in

hypervisor context

* Nov 30, 2006 - release of 4548 kernel, bug still not fixed

* Dec 15, 2006 - first attempt to contact vendor to report bug

* Dec 30, 2006 - public demonstration

* Jan 03, 2007 - vendor contact established, full details disclosed

* Jan 09, 2007 - vendor releases patch

* Feb 28, 2007 - full public release

Patch Development Time (In Days): 6

Severity: Critical (Unsigned Code Execution in Hypervisor Mode)

Vendor: Microsoft

Systems Affected: All Xbox 360 systems with a kernel version of 4532 (released Oct 31, 2006) and 4548 (released Nov 30, 2006). Versions prior to 4532 are not affected. Bug was fixed in version 4552 (released Jan 09, 2007 - not a Patch Tuesday).

Overview:

We have discovered a vulnerability in the Xbox 360 hypervisor that allows privilege escalation into hypervisor mode. Together with a method to inject data into non-privileged memory areas, this vulnerability allows an attacker with physical access to an Xbox 360 to run arbitrary code such as alternative operating systems with full privileges and full hardware access.

Technical details:

The Xbox 360 security system is designed around a hypervisor concept. All games and other applications, which must be cryptographically signed with Microsoft's private key, run in non-privileged mode, while only a small hypervisor runs in privileged ("hypervisor") mode. The hypervisor controls access to memory and provides encryption and decryption services.

The policy implemented in the hypervisor forces all executable code to be read-only and encrypted. Therefore, unprivileged code cannot change executable code. A physical memory attack could modify code; however, code memory is encrypted with a unique per-session key, making meaningful modification of code memory in a broadly distributable fashion difficult. In addition, the stack and heap are always marked as non-executable, and therefore data loaded there can never be jumped to by unpriviledged code.

Unprivileged code interacts with the hypervisor via the "sc" ("syscall") instruction, which causes the machine to enter hypervisor mode. The vulnerability is a result of incomplete checking of the parameters passed to the syscall dispatcher, as illustrated below.

Preconditions (registers set by unpriviledged code):

%r0 syscall no.

%r3-%r12 syscall arguments

Priviledged code:

13D8: cmplwi %r0, 0x61

13DC: bge illegal_syscall

...

13F0: rldicr %r1, %r0, 2, 61

13F4: lwz %r4, syscall_table(%r1)

13F8: mtlr %r4

...

1414: blrl

The problem is that the "cmplwi" instruction compares only the lower 32 bits of the given syscall number; the upper 32 bits are ignored. The "rldicr" instruction, however, operates on the complete 64 bit register value.

The syscall handler address is fetched from the syscall handler offset table at 0x00000000.00001F68+%r0*4. Setting the upper 32 bits of %r0 to something other than 0 will change the upper 30 bits of the address used for the syscall handler offset table lookup. We will now explain how the Xbox 360 security architecture interprets and aliases these upper bits.

When processing the syscall, the processor is running in "hypervisor real mode", with the MMU switched off. However, when accessing memory locations with the MSB cleared, an additional offset, the Hypervisor Real Mode Offset (HRMO), will be applied to all memory addresses.

Due to the Xbox 360 security architecture, main memory is aliased to different addresses with different properties, in order to conditionally enable the security features (encryption and hashing). The hypervisor sets the value of the HRMO special register so that the hypervisor code, including the syscall jump table, resides in memory which is hashed as well as encrypted, even when using zero-based addresses.

When accessing memory locations with the most significant address bit set, the HRMOR setting is not applied. Due to the bug in the "cmplwi" instruction, setting the corresponding bits in %r0 on syscall entry allows setting the MSB, thereby overriding the HRMOR setting and tricking the address lookup of the syscall handler to fetch from memory without any security features.

With the syscall handler offset table aliased to unencrypted memory, the syscall handler table can now be modified to direct the hypervisor to jump to any location in code space that is designated for the hypervisor.

In the proof of concept implementation, a jump to existing hypervisor code is used with a pre-loaded register value as a trampoline to force the ultimate execution path to an arbitrary, unencrypted and executable location in memory.

Proof of Concept Details:

As it is not possible to directly overwrite even non-priviledged code, existing code needs to be tricked into calling the hypervisor syscall with the desired register set. This can be done by setting up a stack frame and forcing a context switch to this stack frame. The bug can be exploited using the following series of physical memory writes:

Setup context switch to stack @80130AF0:

00130390: 00000000 00000000 00000000 FDFFD7FF MSR mask

00130360: 00000000 80130AF0 00000000 00000000 New stack pointer

Setup stack:

00130BD0: 00000000 80070190 00000000 00000000 NIP to context restore

00130C90: 00000000 00000000 80070228 80070228 NIP, LR after context

restore point to syscall

instruction in kernel

00130CA0: 00000000 00009030 00000000 00000000 MSR

00130B40: 20000000 00000046 00000000 80130af0 r0 = syscall nr

r1 = stack

00130B60: 80000000 address1 r4 = address to jump to

00002080: 00000350 points to mtctr %r4,

bctr in hypervisor code

Code to be executed should be placed at "address1", which can be an arbitrary unused memory address.

Example code to output '!' to the on board serial port:

1:

li %r3, '!'

bl putc

b 1b

putc:

lis %r4, 0x8000

ori %r4, %r4, 0x200

rldicr %r4, %r4, 32, 31

oris %r4, %r4, 0xea00

slwi %r3, %r3, 24

stw %r3, 0x1014(%r4)

1:

lwz %r3, 0x1018(%r4)

rlwinm. %r3, %r3, 0, 6, 6

beq 1b

blr

Vendor Status: Vendor was notified anonymously, and after cordial discussions a patch was promptly released.

Recommendation: Remove R6T3.

It looks like the hacker told Microsoft about it and they patched it...

I want to see what Spartan has to say about this..

Link to comment
Share on other sites

it's not like it matters if there is no downgrader. Consoles come with original firmware and are then updated (once the console is online) to the most current firmware, so unless they can write it to a disc and upgrade the original console to this specific firmware, a downgrader will be needed.

Hypervisor isn't perfect, but it's already patched, so I can't see this coming to much...just yet at least

Link to comment
Share on other sites

Xbox 360 vulnerability found, homebrew could be just around the corner

While we appreciate Microsoft's concessions to the DIY gaming community with the XNA Game Studio Express, that's still small compensation for the fact that at the end of the day, that $400 white box in our living room isn't quite "ours" -- Microsoft still calls the shots as to what code can push that hardware around. At least until today. Apparently a vulnerability has been discovered, and while the jargon is rather over our heads, it doesn't take a hax0r to understand the potential upshot: homebrew on the 360. The word is that there's a "critical vulnerability in Microsoft's Xbox 360 that allows privilege escalation into hypervisor mode." Toss in a method to "inject data into non-privileged memory areas" and you've got "an attacker with physical access to an Xbox 360 to run arbitrary code such as alternative operating systems with full privileges and full hardware access." Sounds like a good time for all! The exploit works in kernel 4532 and 4548, but Microsoft is aware of the flaw, and has patched kernel 4552, which was released on January 9th. We can't quite tell if this will actually mean that Joe consumer will end up with homebrew as a result of this hack, but it's promising all the same.

Source: logo_engadget-small.gif

Link to comment
Share on other sites

That just shows how secure they made it this time around, but I figure they can just fix this again.

The DVD drive firmware hack that's been used for backup playback seems to be fixed with them swapping out those drives with the newer BenQs, which are also quieter, and probably cheaper also.

I don't know if the hack still works on these new drives or not though.

Link to comment
Share on other sites

The exploit works in kernel 4532 and 4548, but Microsoft is aware of the flaw, and has patched kernel 4552, which was released on January 9th.

Soooo...:blink: I guess we would have to downgrade our kernels? Count me out of this homebrew business.

Link to comment
Share on other sites

i guess good if you're into modding. i got into the 360 to keep away from that. had enough of it on the PC, i guess. and actually, if you look at PC's, most people never evr do anything with modding, and that's a quite open format. but i do respect the culture, being a car modder myself.

Link to comment
Share on other sites

If you connect to internet with downgraded xbox, it will upgrade again and whats the point of running 360 without XBL and achievements.. I guess someone could make a multi kenel modchip to switch between modded and stock mode but I dont see that happening very soon.

Link to comment
Share on other sites

Why can't MS give us what we want without having to goto homebrew. Give us more video and music playing options and a dang web browser MS... For crying out loud why should we have to consider hacking the console to meet very simple needs? It would definitely increase sells.

Ohh well... I <3 Media Center + Transcode 360 :D.

Link to comment
Share on other sites

I think they'll give us more options like the ones you want, but it'll just take time. People always rush and want things right now. If they get the new bigger HDD out we'll see a update that'll give you more options, like making the 360 a DVR through IPTV? I think that's a future plan for sure. But right now, with the smaller hdd and space limitations, they won't be able to offer loads more options when it comes to multimedia.

I think though, with enough fan pressure, they should add Divx/Xvid playback finally, having it be WMV only is really holding it back right now.

As far as kernel hacks go, it's a big pain to downgrade it right now, not as easy as it is on the PSP etc. Plus, if you have a dual modchip setup, the easy way to get around that, if not through XBL checking your kernel version, then future games could just require the newest kernel version in use at the time. So if you're at 4540 or whatever, and a new game comes out that needs 4600, you'll have to upgrade or not have the game load or options will be missing.

The PSP also does this to an extent, but they've hacked the newest firmwares to let you play homebrew/backups on the newest version also, so you don't have to downgrade anyways.

Link to comment
Share on other sites

If this develops a XBMC 360. Ill buy a second Xbox360 just for this hack, probably keep on in my room or something. I love mods.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.