xbox-scene.com archived forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

xbox-scene.com forum restored.  registration disabled.  thanks to xboxexpert for the db dump and netham45 for cleaning it up!

Pages: [1] 2 3 4

Author Topic: Let The Hacking Begin  (Read 378 times)

'HoRnEyDvL'

  • Guest
NULL
« on: December 04, 2006, 05:06:24 PM »

'
               Well Guys since I�m bored at work I thought I should start a new thread where all people can post there ideas & concepts + results into trying to get the xbox 360 hacked & running some sort of homebrew.
I will monitor this and if I find any useless or repeated posts will be removed.

I�m starting to like vax11780 Post about the buffer overflow but I�m not sure on how much the hypervisor can hold out but its worth the shot. If you guys have any theories or have tried anything please post bellow with the results thanks.

Happy hacking & let the homebrew begin.

Im Thinking we can pull something off by using the fw hack that is out at the moment but havent tried anything yet.

Another posibility is gaining an exploit using the media streaming of the 360 or one of its drivers.
               
               

               
            '
Logged

'OpticNurv'

  • Guest
NULL
« Reply #1 on: December 05, 2006, 12:55:59 PM »

'
               here's everything vax has been saying, just so people can see what's going on with it.

QUOTE(vax11780 @ Nov 4 2006, 02:56 PM) View Post

I grow weary of people who ask 'lets use a buffer overflow in xxxxx' without understanding what a buffer overflow is or how to exploit it.

Simply put, a buffer overflow is a bug in software of firmware. These bugs are usually found in code that processes user input, network stacks, or file handlers. Black hats usually use them to inject custom instruction sequences into a secure system in order to crash the machine, or take control of it.

To understand a buffer overflow, lets talk about how data is stored in most modern computers. There are three types of data available to the programmer: stack, bss, and heap. Microcontrollers implement a fourth (rom) to store static strings like "Hello, World".

Stack or automatic variables are created when a function is entered, and "go away" when the function exits. The data stored there doesn't actually get erased, but may be overwritten at any time by other function calls. Most buffer overflows exploit this type of storage.

BSS or global data is uninitialized storage that is allocated when the program starts, and the data is always available. Most processors (with the exception of microcontrollers) put strings and constant data here as well.

Heap data is allocated and deallocated completely at the whim of the executing program. Since there is usually some variablilty in the order of allocation and release of heap data, it is difficult to execute a buffer overflow here.

For this discussion, I will focus on stack variables. Imagine a computer executes the following code snippet:

CODE

func();
{
    int x,y;
    x = 1;
    y = 2;
    load_font("Nifty.fnt");
    x = y+1;
    y = x+1;
}

load_font(char *name)
{
    int length;
    char font_buff[1024];
    int num;
    FILE *inf;

    // Open the file
    inf = fopen(name,"r");
    if (inf == NULL)
        throw_error("Font file doesn't exist\n");

    // Get the length
    fread( &length, 1, sizeof(int), inf );
    if ( length > 1024 )
        throw_error("Badly formatted font file\n");

    // Load the fonts
    num = fread( &font_buff[0], length, 1, inf );
    if ( num != length )
        throw_error("Badly formatted font file\n");

    // Close file
    fclose(inf);
}


Before executing the function call, the stack looks like this (I'm ignoring complications like the frame pointer, etc)

SP   -> Empty
SP+1 -> 2 (y is stored here)
SP+2 -> 1 (x is stored here)
SP+3 -> return address to 'func' caller
SP+4 -> other stuff

Inside the load_font() function the stack looks like:

SP   -> Empty
SP+1 -> inf
SP+2 -> num
SP+3 -> font_buff
SP+1026 -> length
SP+1027 -> return address to func
SP+1028 -> 2 (y is stored here)
SP+1029 -> 1 (x is stored here)
SP+1030 -> return address
SP+1031 -> other stuff

So, what happens if we load 1032 bytes instead of the 1024 the program was designed for?

Answer: font_buff is loaded completely, length and the return address to func are both overwritten. With the return address changed, when the program trys to return to func it will jump instead to an address of our choosing. If we are clever, and put a hand written piece of assembly language into font_buff, and change the return address to point to it, we can do anything we want.

So, how do you combat a buffer overflow exploit? (I believe the 360 uses most of these, but I could be wrong...)

0) Don't write bad code. Can you spot the bug in the code snippet above? It is similiar to one which compromised the original xbox.
1) Put the stack in memory with the no-execute flag set. This prevents changing the return address to point to the stack from executing code.
2) Randomize where programs get loaded. This prevents the hand tooled assembly language routine from calling a library function to launch an unsigned executable.
3) Sign everything. This prevents someone from changing system files. Note, if the code that checks the signature has a bug, signing may not help.
4) Put the signing key in ROM so it can't be changed.
5) Don't allow writing into memory marked with execute permission. Since memory sections can overlap, you also have to recognize when a data page (with write permission) maps into the same physical memory as a code page.

All for now...

VAX


QUOTE(vax11780 @ Dec 2 2006, 06:52 AM) View Post

After some pondering, I have a buffer overflow that will work regardless of what the hypervisor does. If we put arguments onto the stack for a given function, then change the return address to point to that function, we can force the 360 to execute ANY function loaded (or any piece of a function) by a given program to do our bidding.

Note that this is much more difficult to do than a conventional buffer overflow, but still certainly doable, and there is nothing the hypervisor could do to prevent it.

VAX


QUOTE(vax11780 @ Dec 2 2006, 01:45 PM) View Post

Nope, still need to find some way of causing an overflow. My best guess is in the device drivers for the various pieces (network, hdd, dvd, usb) but it requires people to do some low-level hacking on the raw packet structures. For example, what happens if the DVD drive returns 4096 bytes instead of 2048?

There's a hole somewhere, it just needs to be found.

VAX


               
               

               


                     Edited by OpticNurv, 05 December 2006 - 09:58 PM.
                     
                  


            '
Logged

'peetyboy2006'

  • Guest
NULL
« Reply #2 on: December 05, 2006, 04:03:34 PM »

'
               
QUOTE
i think that the hardware is monitering it so that won't happen and just won't run it or something like that ( i'm not a super kid that know's a lot, but that's what i would think ) if not ok� then i was wrong but i geus they would have build in somthing that makes it inposible to do that


Its not hardware, the hypervisor is software. Its been widley speculated that the hypervisor sits between hardware and guest software (very much like a virtual Pc, if not exactly like one). It has also been speculated that the hypervisor can set up multiple virtual pc's (for emulation of xbox, xna etc...), so that each area can have its own security levels and access.

I like the sound of vax's idea of a buffer overflow, its just going to need someone to test the limits of what the hypervisor can take, and also what will happen if an overflow is attained (may just shut down 360, reset hypervisor etc...).

Id be very willing to help with any "experiments" you may need doing, just bear in mind that im more hardware than software lol so i may not be any use in this situation.

QUOTE
just leave the experts to their work, and before ya know it we'll all be playing n64 wirelessly


Sod the n64, the 360 has enough graphics and cpu power to flawlessly emulate all consoles so far (except ps3 obviously). If it can emulate xbox, then gc and ps2 emulators should be easy peesy lol.

Theres so much potential for this box, once its hacked. Its got more power than a top end pc lol.
               
               

               
            '
Logged

'HoRnEyDvL'

  • Guest
NULL
« Reply #3 on: December 05, 2006, 05:32:45 PM »

'
               Hmm Going through some notes if the Hypervisor is software base because it is it must be initiated somewhere either on boot if thats the case it must be loaded either by Ram Cpu Or Mcpx or its in the kernel somewhere. Best bet is its in the CPU. The only thing is to try beat the hypervisor before it boots so we can try something like corupting it while it checks for hardware, signitures or something else. Not sure if its possible by using the fw we can possibly use it to overflow the hardware. Doesnot the hypervisor or the Kernel check signitures from cd to validate. If we can Overflow the sig check we can possibly cause it to crash it this is just a suggestion i havent really researched it much & not sure if its been tried or not.
Other Possibel Entry Points Might be USB Network or Sata Hdd.
As soon as the hypervisor crashes we dont know what may happen Reset the box Open Up a hole for us Lock Up?
               
               

               
            '
Logged

'HoRnEyDvL'

  • Guest
NULL
« Reply #4 on: December 15, 2006, 06:02:32 PM »

'
               Found something interesing might be some sort of help not sure yet but its a start.
Halo 1 xbox version with demos running on xbox 1 has an option under settings that says demos.
Running same disk on 360 the demos option is removed but why? is M$ scared of something,

So i picked up a random game.
RaliSport Challenge, put it in the xbox 1 & game demos is there hmm interesting lets see it on the 360 ohh look the games demos option is there. Lets try 2 launch it on the 360 now.

" This original xbox game has encountered a  problem & can't continue. For more information go to www.xbox.com/support.

X.5014.0  B1884.0


Hmm why would it be removed from halo & not this game? Did they forget to? is this a way in for us?
Let me know guys thanks.
               
               

               
            '
Logged

'HoRnEyDvL'

  • Guest
NULL
« Reply #5 on: December 15, 2006, 06:26:01 PM »

'
               Hmm interesting. My sega GT2002  + JSRF game disk booted up fine on my 360 could view the demos with no problem but when i tried to play either game a different message came up that said this game is not compatible.

So why did this game/demo selector work fine but not the one on ralisport?

Looks like the xbox 1 emu recheck all libraries before trying 2 boot another xbe within an xbe.
The only thing i can prob see possible is getting multiple supported xbox 1 games booting from 1 dvd with 1 SS. Dont quote me on that tho this is my own speculation.
               
               

               
            '
Logged

'jaimebenlasnow'

  • Guest
NULL
« Reply #6 on: December 16, 2006, 06:43:13 AM »

'
               Tehre is a topic on xboxhacker about that you might be a little interested

original xbox1 dashboard on xbox 360 ?
               
               

               
            '
Logged

'infamous_Q'

  • Guest
NULL
« Reply #7 on: December 16, 2006, 04:24:02 PM »

'
               hey guys, im no computer genius or seriously into hardware programming or ne thing (im in uni for engineering though..so luckily i do have a brain for thought and problem solving). this is just speculation..if this gets deleted i guess it was a moot point. anyways....

we currently have complete control of the dvd drive firmwares right? well remember when people started getting error 61 (i think it was 61) because the fw said the drive was a different version than what was originally mated to their xbox. i have first a question, then an idea. first off, does this mean that the xbox does in fact have the capability of reading the dvd drive's fw? if it does, could you use this to pass too large of a value (assuming i understood the above for Vax) to the cpu when it checks the version?

just an idea, dont know the specifics of how you could do it, but assuming that it would execute the code when read (since my guess is the version code has some sort of assembly equivalent), could you just replace it with an eject drive code or something? if that's the case could we program a jump code (i dont know assembly very well) in place of the version check, which leads to another point in the fw to pass some code to the process that's reading the version? i dont know what could be done w/ this...but it could yield a nice opening, or could just be pointless.

hope this helps.
               
               

               
            '
Logged

'HoRnEyDvL'

  • Guest
NULL
« Reply #8 on: December 20, 2006, 07:00:58 PM »

'
               Hmm i still think we can break in using software but where do we start sad.gif
               
               

               
            '
Logged

'infamous_Q'

  • Guest
NULL
« Reply #9 on: December 21, 2006, 09:02:12 AM »

'
               imo it'd be the firmware, because we have control of it and we know the main process has to read it, or at least specific information from it, at one point or another.

i dunno if this makes sense...but if we have the processor read a specific variable or value that we wanted, to use later, as something from the FW, if it stores it could we use a function from the fw chip to run using that variable, thus sort of achieving what vax was talking about?
               
               

               
            '
Logged

'slayer410'

  • Guest
NULL
« Reply #10 on: December 21, 2006, 11:15:19 AM »

'
               HoRnEyDvL, hit me up on AIM and I'll give you a possible exploit theory. ~Highly Likely

lilballer4yu
               
               

               
            '
Logged

'jameswalter'

  • Guest
NULL
« Reply #11 on: December 22, 2006, 10:41:20 AM »

'
               
QUOTE(infamous_Q @ Dec 21 2006, 09:09 AM) View Post

imo it'd be the firmware, because we have control of it and we know the main process has to read it, or at least specific information from it, at one point or another.

i dunno if this makes sense...but if we have the processor read a specific variable or value that we wanted, to use later, as something from the FW, if it stores it could we use a function from the fw chip to run using that variable, thus sort of achieving what vax was talking about?


As far as we know the 360 only looks at the device identifier to determine the drive version.   The entire firmware isn't read, so I don't think this will be a way in.  The DVD firmware is basically a seperate entity.  It has no idea what it is connected to, it's just instructions on how to read the discs that are inserted into it, and how to pass the data onto that SATA interface.  No exceutables are being executed on the DVD drive, just data transferred to the 360, then once that data is verified it is run.  


....and what happened to being serious hackers only....TomDizzle is just a damn troll doing nothing to further the conversation in this thread.
               
               

               
            '
Logged

'infamous_Q'

  • Guest
NULL
« Reply #12 on: December 22, 2006, 02:56:13 PM »

'
               yeah i was hoping that maybe the seperate entity thing could be overcome. hmm.....lol i also just realized that if it gets a wrong value it'll pop up w/ error 66. is it possible that if an error is being experienced the hypervisor would go down? after all teh system does lock doesn't it? if that's the case then that may be a way in.
               
               

               
            '
Logged

'HoRnEyDvL'

  • Guest
NULL
« Reply #13 on: December 22, 2006, 03:51:38 PM »

'
               slayer410 i dont have aim just post it here.
               
               

               
            '
Logged

'FrEaKsHoW12390'

  • Guest
NULL
« Reply #14 on: December 22, 2006, 07:16:43 PM »

'
               yes please do we all are apart of the scene so we all need to hear it am i wrong cause if it works it will get out anyway
               
               

               
            '
Logged
Pages: [1] 2 3 4
 

Page created in 0.15 seconds with 16 queries.