Print

[Xbox-Scene]

Success Editing Xbox 360 Shaders-- Posted by XanTium on December 30 21:43 EST
Tser posted some interesting findings over at the xboxhacker.net forums.
He tried editing the shaders of the game 'King Kong' and see if the Xbox 360 would run (allow) it (using the demo on the Kiosk Demo Disc of course as it would be impossible to test this with the retail game that only boots from DVDXBOX(360)):

This game uses vector shaders, compiled with Microsoft D3DX9 Shader Compiler 9.04.91.0000. Both Vector Source and a .Bin files are there.
Not that it will lead to anything, but it would be intersting if we can modify the shaders of that game... specially because it is rumoured that high level vector shaders have access tot the system memory as well.

I am trying to figure out 3 things here:
1/ Is it possible at all to mess with the shaders (simple replace blue water by red water) -> has been done as of 30-12-2005
We modified the shaders of the king kong demo. AO created All yellow shaders. Check result.
The shaders are compiled run time... so you just can edit script files.
For example, to let it be all white: return float4( 1.0f, 1.0f, 1.0f, 1.0f);
2/ Is it possible, to read from any memory location at all ,using an array overrun -> would really be useful, but i doubt if the gpu has no overrun protection
3/ Is it possible to write to that memory also -> sounds currently too impossible to believe for myself :-)

We need however some assistence on this, as I never have coded shaders before... expert help on this topic would be great. Help out on this XBH thread [please remember - topics in the XBH technical forums are for technical discussion only, not speculation or questions].

News-Source: xboxhacker.net

[monkeychris]

well, although ive had a bit to drink... it is 3.00am

using a buffer overrun/underrun technique still seems impossible due to the hypervisor etc.  BUT still worth trying, whoknows when the visor stops its routines... (poss after xbe verified... [although doubtful!])

i havent a clue about directX exploits, and im in no state to look for any; but it would be assummed any 'illegal' code would be picked up

the fact your can change shaders, may lead to cheating on a xbox live compatible game, if your swap for a full game (possible?) and have a mod version (IE counterstrike with with opponents...)

as for running unsigned code, hmm....

would MS leave memory open to GPU without checks?
does the DX equiv have unrellented power?
can this give you illegal backups..........?

who knows, to be honest who really cares?

a hole like this is easily fixed by MS...

simply put a kernal update that stops execution of this XBE on retails.  they arent gonna be bothered if this puts retailers out of there way, just send em a new disc / download...

download you say....  well yes, do you really think the media flag wasnt set on this disc by mistake....

I will enquire with my uk MS PR sources in Jan but i would presume that the disc is meant to be downloaded and run of a DVDR.  (someone check the flag for me, but i think its any  booktype, not no booktype {which means its on purpose])

who knows if what i say is spot on...  but this is not a slip up by MS... it gives us nothing as of yet...

the SDK we have gives us more than this (wink, wink)

ive said nothing wrong i dont think dont ban me


PS ive noticed somewhere on XS someone closing threads that may be quite important ;P  and letting bollox ones ramble on, mods these days, thay arent like they used to...


(i like the fact no-oneknows who i am, being anon gives you more power than being a hero)

[lobango]

what are you talking about memory attacks?  it is compiled at run time and since the gpu shares memory with the cpu, full control of gpu can pretty much run any code loaded by it.  we just have to see how much control we can get

[ibemonty2000]

I wish I actually knew what their talking about...

-Monty

[mlapaglia]

if it gets a softmod/modchip out any faster, i say let them talk it up.

[monkeychris]

QUOTE(lobango @ Dec 31 2005, 03:33 AM)

what are you talking about memory attacks?  it is compiled at run time and since the gpu shares memory with the cpu, full control of gpu can pretty much run any code loaded by it.  we just have to see how much control we can get

well it shouldnt be hard to buffer overflow memory from here, but visor will pick it up no doubt?

how else can we do it?  

\
ideas please > if we could get illegit code into memory & bypass visor then good days...

[lobango]

QUOTE(monkeychris @ Dec 31 2005, 04:56 AM)

well it shouldnt be hard to buffer overflow memory from here, but visor will pick it up no doubt?

exactly, the hypervisor will pick up code that doesn't belong.  there's no way around the hypervisor either.

i dont know how exactly the hypervisor checks the memory but hopefully if the gpu compiles something and loads it into memory, basically saying that's valid code, then it'll run fine.  i have doubts about how much this shader technique will work, i dont think it gives enough freedom and probably can't link/compile things that we really need, but who knows.

[Chris_F]

Buffer Overflows are themselves and exploit. The shaders too are a possible exploit, so you wouldn't use the shaders to perform a buffer overflow because where is the point in using an exploit to just to exploit something else? What I'm trying to say is that the shaders themselves may be a way to run unsigned code, ie. no buffer overflowing required.

Anyway, I think the idea is to use a high-level vertex shader to access the system memory and load it's own executable code in there. At least I think. It's very late here and I know nothing when it comes to DirectX and shaders.

[lobango]

and to add to my doubt, i'm pretty sure that even though the memory is unified, the cpu will know which binaries to run.  i don't see how the gpu can control the cpu

[Chris_F]

QUOTE(lobango @ Dec 31 2005, 02:34 AM)

and to add to my doubt, i'm pretty sure that even though the memory is unified, the cpu will know which binaries to run.  i don't see how the gpu can control the cpu

Well if the shaders have access to the portion of memory that is used by the cpu it could be possible for it to modify any peace of code. The only problem is whether or not the shaders can access that part of memory or if it's protected.

[Avenger 2.0]

Me thinks MS is going to ban this Kiosk Disk in their next update

[Monoxboogie]

QUOTE(Chris_F @ Dec 31 2005, 08:06 AM)

Buffer Overflows are themselves and exploit. The shaders too are a possible exploit, so you wouldn't use the shaders to perform a buffer overflow because where is the point in using an exploit to just to exploit something else? What I'm trying to say is that the shaders themselves may be a way to run unsigned code, ie. no buffer overflowing required.

Anyway, I think the idea is to use a high-level vertex shader to access the system memory and load it's own executable code in there. At least I think. It's very late here and I know nothing when it comes to DirectX and shaders.

It sounds like you have a very vague understanding of buffer overflow exploits.

Essentially, a user space program writes data into address space addressable by the entire system (such as environment variable on Unix; it cannot just write it into it's own address space, as there is separation of program address space, and a GPF occurs if it's attempted).  Then, the exploit program provides data to an unchecked buffer in the program.  There is so much data provided that it ends up overwriting critical data structures, including some important register values, such as EIP.  It writes the address of the code to the EIP.  Then, when the vulnerable program returns from a function call, it pulls the overwritten value off of the stack, to EIP, and jumps there, running the code that's there.

Unless I am seriously mis-understanding the shaders, that is essentially what we're trying to do.  The shaders just happen to be the vulnerable "program," and the shader files just happen to be the exploit "program".  Even if we use shaders to inject the code into the shared memory, we still have to overwrite the EIP for the CPU to execute the instructions.

Or perhaps I just severly misunderstand the relationship between the GPU/CPU/Shared Memory.

[Chris_F]

QUOTE(Monoxboogie @ Dec 31 2005, 10:33 AM)

It sounds like you have a very vague understanding of buffer overflow exploits.

Essentially, a user space program writes data into address space addressable by the entire system (such as environment variable on Unix; it cannot just write it into it's own address space, as there is separation of program address space, and a GPF occurs if it's attempted).  Then, the exploit program provides data to an unchecked buffer in the program.  There is so much data provided that it ends up overwriting critical data structures, including some important register values, such as EIP.  It writes the address of the code to the EIP.  Then, when the vulnerable program returns from a function call, it pulls the overwritten value off of the stack, to EIP, and jumps there, running the code that's there.

Unless I am seriously mis-understanding the shaders, that is essentially what we're trying to do.  The shaders just happen to be the vulnerable "program," and the shader files just happen to be the exploit "program".  Even if we use shaders to inject the code into the shared memory, we still have to overwrite the EIP for the CPU to execute the instructions.

Or perhaps I just severly misunderstand the relationship between the GPU/CPU/Shared Memory.

I have a very thorough understanding of buffer overflow attacks, thank you very much. After all, I only found and exploited one in Gaim's away message.  (IMG:style_emoticons/default/wink.gif)  (It was quite fun to see the looks on my friends faces, of course I did no real damage and reported the bug immediately)

Again, the shaders could be a way to load code into memory, not overflow any buffer. Besides, I think MS has made it clear that buffer overflow attacks will not work on the 360.

[bowser22]

This could be a good way to exploit the 360,although as chris f said stack memory on the 360 is non executable making it nearly impossible to cause a buffer overflow because the kernel always checks to make sure the 360 is only running signed code if its not the 360 immediately shuts down
Good work

[lobango]

QUOTE(bowser22 @ Dec 31 2005, 08:22 PM)

This could be a good way to exploit the 360,although as chris f said stack memory on the 360 is non executable making it nearly impossible to cause a buffer overflow because the kernel always checks to make sure the 360 is only running signed code if its not the 360 immediately shuts down
Good work

i really dont think you know what you're talking about, only regurgitating random bits of information you read around.

the kernel checksums the memory.  it's not a matter of signed code right now.  as of right now this shader thing (if it can even modify code in memory that the cpu uses) is probably useless