xbox360 hombrew nearly there!

fes_786

Inactive User
Joined
Nov 30, 2005
Messages
3,894
Reaction score
277
Location
uk
>> This was posted moments ago on Security Focus' BugTraq list and looks like a follow-up to the anonymous 23C3 Hacker Congress presentation held end december. Looks like some huge news (Unsigned Code Execution in Hypervisor Mode) even if it's already patched by Microsoft in the latest kernel release:

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.

according to this old kernal can run hombrew if u code it properly

and that the bug has been patched

well we alread can downgrade the kernal

and by the looks of it the could be small scale hacks within 2-3 months for hombrew

the hypervisor is like a giant complex firewall
and only things that are signed can work

now this is some excellent newz
 

deedie

Inactive User
Joined
Nov 21, 2005
Messages
3,509
Reaction score
236
well over my head all that stuff. but it sounds interesting.
 

zerofool2005

Chilld/Teenage Member
Joined
Feb 23, 2007
Messages
518
Reaction score
0
Ahh i love Microsoft saying "The most security thats ever seen" and they seriously get pwnd in the ass now lets see how vista did?
 

fes_786

Inactive User
Joined
Nov 30, 2005
Messages
3,894
Reaction score
277
Location
uk
Ahh i love Microsoft saying "The most security thats ever seen" and they seriously get pwnd in the ass now lets see how vista did?

hi m8 dont forget that the xbox360 been out 4 a while and no home brew

but if u took the update the jan 07 one

well ur stuck then because u cant downgrade that... because it blows a efuse in the cpu so if u load old kernal it wouldnt work

because of a check on efuses

but compared to other consoles the hypervisor is a very intellignet and very complicated programme

but its fatal flaw is that of u take over the hypervisor ur in control of the machine

at the moment they tricked it to run unsigned unencrypted code

remeber the presentation were a masked hacker demonstrated on projecter linux and mac logo's

he had a few wires and somthin that looked like a jtag or similar hooked up to laptop and xbox360

still a way off gettin full control of the hyper visor
 

biffo1

Moderator
Staff member
Moderator
Joined
Dec 5, 2006
Messages
9,096
Reaction score
2,124
Location
Manchester
its nice to be 1 step ahead from smart arses from microsoft
 

i-zombie

VIP Member
VIP Member
Joined
Oct 22, 2005
Messages
3,749
Reaction score
90
Location
leeds
'Hello World' - First Public Homebrew Code Running via Hypervisor Exploit
>> Crawler360 released what looks like the first 'homebrew' program that you can run on a retail Xbox360 using the Xbox360 Hypervisor Vulnerability released Tuesday. The program itself will just display a "Hello, world!" message, so you can see it as a proof-of-concept of the Hypervisor Vulnerability using the King Kong shader 'hack'.
However this isn't a hack the average end-user can try-out already, as for now it'll require the King Kong game, a modified DVD firmware or disc-swap (which are both still fairly easy to do), but you will also have to connect the serial port on your Xbox360, compile the code from sources yourself and you'll need kernel 4532 or 4548 (most of you are probably already updated to the patched 4552 kernel - and right now there's no way to downgrade as Microsoft probably blew up an eFuse to prevent kernel downgrades). If you have a kernel below 4532/4548 you can upgrade 'safely' to 4532 using the burnable HD-DVD software update called HD_DVD_10-2006.zip (the readme includes an URL for it on the MS servers, but the file is already offline ... however I'm sure it'll still out there somewhere, the md5 is cd4db8e2c94266ab73513c361dd5b8f6).

From the readme/nfo:
Xbox 360 Hypervisor/King Kong Exploit

Thanks to Anonymous Hacker's great work, I' m now able to publish my own little implementation of the exploit.

I've used the full version of the King Kong (KK) game, as it has been shown to work by these anonymous people at 22C3, and it was the first one I found with editable shaders. Most games have these - KK was just the first one I've checked.
So you need a KK full (USA or PAL doesn't matter, they are the same) DVD image (including video partition), and obviously a hacked drive firmware.
You could also try hotswapping from your (hopefully existing!) KK original to the modified copy. Then you could go with a stock firmware.
Why not using the KK demo? It would work the same (though the shader file format is different), but requires a firmware hack too, as the possibility to run it from DVD-R was blacklisted in a very early kernel already, which doesn't have the vulnerability.

So, how does the hack work? Basically, the bugtraq post (http://www.securityfocus.com/archive/1/461489 in case you haven't read it yet) explains it all. All I did was to convert the series of memory writes into a shader, and writing a small serial loader stub.

You need to connect the serial port to use this hack. Read Speedy22's fine "Xbox 360 Motherboards and Headers" documentation, it's on J2B1.
NOTE: It's LVTTL. Do not even think about connecting to an RS232 port directly.
RS232 is +-12V, LVTTL is 3V. Think about what's happening when you connect your 110V equipment to 220V. You don't want to happen that on your southbridge. ;)
For example, use a MAX3232, or just use any of these USB serial port adapters which already output 3.3V.
Speed is hardcoded to 115200/8N1.

To modify your existing game image, start the "patcher" tool. It will patch your game image to include the loader. It is a bit lame, but works. The tool will also remove the three startup videos for a faster boot.
When you launch the modified game, it will directly go to the main screen.
Press start on a controller. It should display "LOADING", and then freeze while displaying "Acessing Content". If it doesn't freeze, you don't have the correct kernel version (4532 or 4548, but only 4532 was tested). See below on how to update.

Now, the serial loader gets active. You should see a "Xe>" on the serial port. Now, upload your binary code (just as a binary blob). To terminate your upload, send 16x 'x'. It will be loaded to 0x01300000, and executed.
Be warned, only CPU #0 is trapped. The other threads/cores are still happily executing, so you need to catch them.

"Hello, world!"
Use the source, luke!
compile with
powerpc64-linux-gcc hello.S -o hello.o -Ttext=0x1300000 -nostdlib
objcopy -O binary hello.o hello.bin

HOWTO UPDATE (to the correct kernel)
To clarify things again:
* If you have 4552, you are screwed. Sorry.
* If you have 4532 or 4548, it has to work. If it doesn' t work, something else is wrong, but please don't try to update.
* If you have pre-4532: Grab HD_DVD_10-2006.zip [URL in readme is already offline] (check MD5SUM first: microsoft could have changed this file! the correct md5 is cd4db8e2c94266ab73513c361dd5b8f6). Burn it to a CD, and start it. It will update your console to 4532.
 

Munkey

DW Regular
Joined
Jan 27, 2006
Messages
5,849
Reaction score
179
Thanks for posting. Seems like some homebrew software finally on the horizon. I'll take there word for it though. All that stuff to see the hello world message lol.

I was just about to build a HTPC but if the 360 is going to be hacked then maybe I should wait.
 

fes_786

Inactive User
Joined
Nov 30, 2005
Messages
3,894
Reaction score
277
Location
uk
how do they find this stuff out??? it boggles the mind :)

hours of testing, researching, talking, leaked info, and fookin up a few consoles, and having quite a bit of cash and know how

these guys who figure it out from the begining are awsome

lol
 

hollow

Inactive User
Joined
Jun 4, 2005
Messages
645
Reaction score
23
the ones that figure things like this out are the ones microsoft should be employing

that why there security would be so much better and hacks etc would be alot harder to do
 

fes_786

Inactive User
Joined
Nov 30, 2005
Messages
3,894
Reaction score
277
Location
uk
the ones that figure things like this out are the ones microsoft should be employing

that why there security would be so much better and hacks etc would be alot harder to do

lmao there will always be someone who will figure it out

and u cant be serious about making the security tighter?

were lucky we got backups going becasue of outsourced dvd drives


if they made them they would of integrated hyper visor cheking then we would of been screwed
 

i-zombie

VIP Member
VIP Member
Joined
Oct 22, 2005
Messages
3,749
Reaction score
90
Location
leeds
were still a long long way away from anything remotely useful or simple enough fo r everyone to try

this may lead to something but its not the big news folk are hoping for
 

fes_786

Inactive User
Joined
Nov 30, 2005
Messages
3,894
Reaction score
277
Location
uk
were still a long long way away from anything remotely useful or simple enough fo r everyone to try

this may lead to something but its not the big news folk are hoping for

true m8

u have to know ur stuff even to try this and mine i got it to say hello world

lol its good fun but we need somthing better

better like proper home brew which every tom dick and harry can do
 
TEST
Top